Far better than database per tenant.

The better isn’t clear here, why is it better?

Database per tenant - barring configuration errors to a connection string or something along those lines - means you won’t ever accidentally leak over other customers data

With Row level security, as good as it is, there is always a chance of leaking happening, due to bugs, user error or the like

Database per tenant also makes migrations safer, and allows easier versioning of an application, for example if you run a SaaS you may put your V2 application into permanent maintenance mode and allow existing customers to use it in perpetuity, while upgrading customers and new customers are put on the V3 platform. This is infinitely easier in practice when the database is per tenant

Many of our clients eventually want to host our app on-premises, so moving it to an on-premises environment is quite easy with the database-per-tenant approach. Just copy the database as is.

That’s not correct. It’s hard isolation. In effect, RLS automatically applies a where clause preventing developers inadvertently accessing the wrong data.

If you don’t set the Postgres environment variable then no data is returned.

All the hard isolation without the schema sync pain.

Right, but this assumes that you have a) remembered to enable RLS for every table where it matters and b) configured appropriate rules perfectly for every table. And there are tons of things you can mess up in the rules.

With per-tenant instances none of those things can happen.

https://www.postgresql.org/message-id/24478.1109618520%40sss...

For example:

  SELECT * FROM hackernews_history ORDER BY time DESC LIMIT 10;

I subscribe to this issue to keep up with updates:

https://github.com/ClickHouse/ClickHouse/issues/29693#issuec...

And ofc, for those that don't know, the official API https://github.com/HackerNews/API

1. Create a table with styles by authors:

    CREATE TABLE hn_styles (name String, vec Array(UInt32)) ENGINE = MergeTree ORDER BY name

    INSERT INTO hn_styles WITH 128 AS vec_size,
    cityHash64(arrayJoin(tokens(lower(decodeHTMLComponent(extractTextFromHTML(text)))))) % vec_size AS n,
    arrayMap((x, i) -> i = n, range(vec_size), range(vec_size)) AS arr
    SELECT by, sumForEach(arr) FROM hackernews_history GROUP BY by

    SELECT name FROM hn_styles ORDER BY cosineDistance(vec, (SELECT vec FROM hn_styles WHERE name = 'antirez')) LIMIT 25

        ┌─name────────────┬─────────────────dist─┐
     1. │ antirez         │                    0 │
     2. │ geertj          │ 0.009644324175144714 │
     3. │ mrighele        │ 0.009742538810774581 │
     4. │ LukaAl          │ 0.009787061201638525 │
     5. │ adrianratnapala │ 0.010093164015005152 │
     6. │ prmph           │ 0.010097599441156513 │
     7. │ teilo           │ 0.010187607877663263 │
     8. │ lukesandberg    │  0.01035981357655602 │
     9. │ joshuak         │ 0.010421492503861374 │
    10. │ sharikous       │  0.01043547391491162 │
    11. │ lll-o-lll       │  0.01051205287096002 │
    12. │ enriquto        │ 0.010534816136353875 │
    13. │ rileymat2       │ 0.010591026237771195 │
    14. │ afiori          │ 0.010655186410089112 │
    15. │ 314             │ 0.010768594792569197 │
    16. │ superice        │ 0.010842615688153812 │
    17. │ cm2187          │  0.01105111720031593 │
    18. │ jorgeleo        │ 0.011159407590845771 │
    19. │ einhverfr       │ 0.011296755160620009 │
    20. │ goodcanadian    │ 0.011316316959489647 │
    21. │ harperlee       │ 0.011317367800365297 │
    22. │ seren           │ 0.011390119122640763 │
    23. │ abnry           │ 0.011394133096140235 │
    24. │ PraetorianGourd │ 0.011508457949426343 │
    25. │ ufo             │ 0.011538721312575051 │
        └─────────────────┴──────────────────────┘

What are some salient counter points for choosing next.js? I see a lot of new devs not want to have to think about deployment and management of systems so that is one aspect. If you only know react I guess getting SSR without having to learn something else is a win at the cost of complexity in your codebase.

Anything else?

There is a lot of magic and complexity under the covers that I haven't fully groked, and from that perspective I have reservations about it, especially after the recent CVE. As an example of the complexity, I had to set up Sentry, and while Sentry does have a package specifically for next.js, it was still tricky to ensure we were capturing errors with appropriate context in every possible spot.

It's possible as our project matures we'll hit some roadblocks that will make us question our decision to use next.js and self host, but overall our dev team has been productive with it.

Well there are alternatives to Next.js that handle SSR. Remix for example. That's a popular one.

For a smaller project I wouldnt be afraid of rolling your own with Vite. It's pretty simple.

And for any developer I'd really recommend implementing SSR yourself with an express server or whatever. It really increases your understanding of how frameworks work.

Maybe people should rediscover the joys of just FTPing files on a cheap host.

It's not like most project will have problems running on those hosts. And if it is the case scaling is one bare metal server + nginx away.

https://pgs.sh

Unfortunately, Next.js dials back static export support with every major release, but it is still usable to create a 100% SPA with static export.

Wasn't it even originally created to produce static websites?

But, man, at that point you're bringing a bulldozer (with a super uncomfortable operator's station!) to drive a nail.

I think I do exactly the opposite. Having no SSR but everything be statically exported allows me to get away with cheaper hosting on the backend side (the REST API is on a cheap VPS). Static exported SPA means, the user's browser does all the heavy rendering. Plus, no AI bots or search engines contribute to my server's load.

Additionally, the site is fast. Not sure if you know how Next.js works, but since the initial load is already prerendered and just static html+js, it loads instantly. Then hydration happens in the background, unnoticed by the user and the actually JS takes over. JS+CSS are chunked where possible, and Nextjs employs a neat trick: It pre-loads the js+css for the next page once you mouse hover over a link - whether you click it or not. Also increaes the user-perceived speed. Plus, since all js chunks have its sha1 hash in the filename, they can be served with long caching times (even immutable, so cached forever) - once you loaded the website, recurring visits will be blazing fast.

If you want to try it out, the url is https://lockmeout.online - although I do not use a CDN and host verything on a cheap hetzner VPS - hence loading time might be higher outside europe.

Building a static website is very reasonable. Using the monstrosity that is Next.js to build a static website seems like super overkill, and I am not sure it offers a good developer experience to justify it[1].

[1] My experience with it had a need for dynamically driven pages, so it may just be that it's horrid design is only a problem once you move past static page generation.

API routes in same codebase that can use same TypeScript types instead of these typegen tools is really nice too.

I'm very much in the camp of not fiddling with build, routing, hydration, state, etc. as they end up being a distraction from just making the thing you set out to make.

Using something else, means not having support, and spending time yak shaving instead of coding the real solution.

From Java/.NET ecosystem point of view, Next.js is the framework where I feel at home.

I work with agencies that have partner agreements with Vercel/Netlify, which makes it a good option for SaaS products that are in the MACH architecture space.

Julia for mathy stuff.

Python with pandas / polars.

Rust with polars / actor frameworks.

Go for simple systems tooling / api dev.

Zig and Rust for systems programming.

Elixir / gleam for functional webdev.

JS / TS for everything.

But one of Scala's strength is versatility. You could use it quite well for all the listed use cases too. With just one language. (Maybe with the exception of system programming -- Scala Native still requires a tracing GC.)

Also, it's worth noting that Scala is more popular/mainstream/supported/has bigger community than Julia, Zig and Elixir / gleam. And if Red Monk is to be trusted, even more than Rust https://redmonk.com/sogrady/2024/09/12/language-rankings-6-2... That comes with many benefits.

> if you don’t need JVM / Java interop

OpenJDK is also very good, even if it's not a strict requirement to use it. Battle-tested, easily debugable, etc... AOT compilation is possible via GaalVM's native-image.

Or you can try Scala.js or Scala Native (which don't have anything to do with JVM).

I think that the jack of all trades space is already occupied by C#.

Anyway - your profile resonates with me. Would love to grab a virtual coffee if you are up for it.

Quality seems completely lost as a goal in any shop. See Demming and Peopleware.

In very general terms: "founder mode" is more often than not toxic because it is taken out of context and used to scapegoat being an asshole. Much like the Steve Jobs worshipping of yesteryear.

Lack of financial oversight by board/investors including founders putting up company money for personal investments including moving money into personal accounts to try and inflate their credit ratings.

Non-VC startup: lack of preparing for a future where income is reduced for a period of time and keeping some amount of business savings around

VC startup: lack of appropriate fund handling given the assumption that the money machine will always be there

Hurting all option holders by removing the ability to exercise early or ruining their exit with poor financial stewardship including down rounds or bridge rounds

Always time to fix it later vs taking the time to plan and execute correctly in the first place. This is a relative scale of time to market and risk to opportunity cost but with the exception of large events like tradeshows or such a few more weeks to get it right is better than hobbling along with literally millions of dollars of technical debt if success is found.

And re:tradeshows - demoware is the name of the game and sales needs to be onboard with eng that demoware is demoware and what to sell ahead of the product

Lack of clear execution plan as product market fit is found and everyone has been acting in "throw shit on the wall to see what sticks" mode

General lack of discipline to keep things orderly as work is done which is a failure to understand systems and second / third order effects. Speed is a lagging indicator not a leading one. Everyone wants more, faster but then fails to slow down to put process in place to facilitate moving faster.

Not growing teams appropriately. Lots of lack of empathy, poor hiring practices, abysmal firing practices. Lots of tolerance of "smart assholes" in small teams when leadership only cares about P/L and so the toxicity grows.

https://en.m.wikipedia.org/wiki/Martin_County_coal_slurry_sp...