revenut-app VS pgpkg

> If you maintain an open-source project in the range of 10k-200k lines of code, I strongly encourage you to add an ARCHITECTURE document

Regardless of repo size, I think architecture still has a place in a Readme. I did a Mermaid sequence diagram in the main Readme because I think it's important that all readers see and understand how this particular project works:

https://github.com/hbcondo/revenut-app?tab=readme-ov-file#-w...

https://github.com/hbcondo/revenut-app

I built this web + mobile app (PWA) written in React Native + TypeScript that does simple revenue forecasting for a SaaS that uses Stripe.

Stripe's mobile app and others kinda do this already but some of their numbers can be inaccurate (as detailed in the repo's readme) so that made me open-source + solve an issue my own SaaS[1] has with Stripe.

[1] https://Last10K.com

Thanks for sharing! I generated a png and added it to my repo's wiki with an acknowledgment to your repo:

https://github.com/hbcondo/revenut-app/wiki#data-models

IMHO, It depends on what you want to do:

I use WordPress for managing large amounts of content at https://last10k.com

I use ReactNative + TypeScript for developing a cross-platform mobile app at https://github.com/hbcondo/revenut-app

I selected Phoenix's LiveView for real-time streaming at https://last10k-com-live.fly.dev/filings (in progress)

https://github.com/hbcondo/revenut-app/commit/740f907d42e189...

[1] https://www.pinta-project.com

I've been building Revenut, a web + mobile app (PWA) built in React Native + Typescript that does some revenue forecasting for a SaaS that uses Stripe as their payments provider. Stripe's mobile app and others kinda do this already but there are issues as noted in the repo's readme that made me go out on my own and open-source & solve an issue my own SaaS faced with Stripe:

https://github.com/hbcondo/revenut-app

You are absolutely correct; my previous business ended up ejecting almost all database logic from Java ORMs, and moved almost everything to SQL and stored procedures. Doing so resulted in a significant performance and productivity increase, relative to all the layers of nonsense we used to jump through.

One of the difficulties of doing this was that the tooling isn’t great. We had to write our own tools to make it work, but the benefits of going back to SQL were more than worth it.

(Many years later I made an open source version of that tooling, https://github.com/pgpkg/pgpkg)

I wrote something [0]. It lets you write plpgsql functions, views, triggers and casts in a way that can be re-created without migration scripts. It’s a complete work in progress, not production ready, probably has bugs, but I use it daily. It lets me use Postgres as my main development environment.

It also managea migrations for tables, types, and other stuff, if fully atomic, and lets you write unit tests in SQL (which run inside save points so they don’t affect the database and can run during production deployments). It’s sort of my Swiss Army knife of plpgsql development.

[0] https://github.com/pgpkg/pgpkg

I use static Svelte(Kit) + TypeScript + Tailwind on the front end, Go and Postgraphile in the middle, and PostgreSQL functions on the backend.

I did write my own PostgreSQL migration tool though, to make it easier to write SQL functions in my IDE: https://github.com/pgpkg/pgpkg