Is database agnostic best for Blitz?

[flybayer]

A discussion started in Slack recently that's worthy of a home here as a discussion thread.

Jay Araujo: @flybayer curious what your motivation was to turn the prisma layer into a plugin? will the app code change at all if not using prisma? I mean, evrything being optional is both the blessing but also the curse of frameworks such as Express.js. I was under the impression that one of the goals of Blitz was to cut the amount of choices a developer has to make by offering an opinionated framework. Was that ever really a goal, and how are you guys drawing the line?

Me: Jay Araujo you’re right about that being a goal. In this case we accomplish that by having Prisma as the default choice and set up for you. But the DB layer is something that varies way too much among apps to force a single solution for it. There’s a big difference between having nothing by default with stuff optional and something by default with stuff optional.
This is part of our foundational principle of “Loose Opinions”. The opinion is that Prisma is best for most people, but it’s a loose opinion meaning you can easily swap it out for something else
If not using prisma, all your DB access code will change.

Simon Edelmann: Are we sure, we want the db layer to be a loose opinion? So many things depend on prisma: authentication, sessions, generated queries/mutations, even generated pages. If we remove prisma and everything depending on prisma, what else will be left?

Jay Araujo: @flybayer I see. The term plugin kind of gives off the idea of something that is opt-in, but what you are telling me it's that it's opt-out. So no wonder why it was a bit difficult for me to reconcile those two ideas. What Simon says (absolutely no pun intended!) actually resonates with me in the sense that having a persistance layer that is fully swappable sounds more like a v2 kind of goal than something for the early stages. Needless to say these are just the naive impressions of someone that has so far mostly following the project from a distance. But to sum it up and offr you an outsider developer's point of view, one of main things that keeps me interested on Blitz is the promise of a safe-heaven from one of the biggest problems in the JS ecosystem: technology fragmentation. But if I login here tomorrow and 20% of the questions are for Prisma, 20% are for GraphQL, 20% are for Firebase and 40% are for any of 10 other possible db layers, honestly if feels like going back to square 1 😂. Just my 2 cents 😉

[flybayer]

@simonedelmann it's not quite accurate to say that all those depend on prisma. Auth and sessions do not depend on prisma. The only thing is you don't get zero-config auth without prisma (but other db plugins could provide this). But yes generated code currently depends on prisma. The main thing that matters is that the generated code is decent for the default happy path (Prisma), so we wouldn't have to make it work with every other database. We're adding custom templates which most people will use anyways. However, we can set up plugins so that db plugins can provide templates. In this case, everyone can get decent default templates.

Also, keep in mind I think the biggest benefit of Blitz is the zero-API data layer. It's not code generators. You can easily add code generators to any project and the default templates aren't that great for production apps anyways (thats where custom templates become useful).

[flybayer]

Blitz is the promise of a safe-heaven from one of the biggest problems in the JS ecosystem: technology fragmentation.

Jay, yes for sure and that will remain :) I think where the database discussion differs here is that DB fragmentation is a different thing than JS fragmentation. With JS, there are many libraries that do the same thing slightly different with basically the same result. But with databases, different database can be required based on the app and what it's doing. For example many apps do great with Postgres, but some require a document DB like DynamoDB, or a graphDB like Neo4j.

The other point is that even if we don't have db plugins, people are still going to use other databases. You can use other databases with Blitz right now. You just don't get the benefit of blitz db cli commands and the codegen doesn't work for you.

So if people are going to do that anyways, we might as well make their experience as good as possible, right? Especially because this has zero negative affect on the default happy path.

[simonedelmann]

It's obvious, you have thought about this much longer than I did when I wrote my first comment. ;)
Everything sounds good, especially with Prisma opt-out! I think we should just make sure that Prisma gets enough focus.
(I was a little afraid we could have some loose ends everywhere. Prisma integration should not suffer from the fact we start supporting many databases.)

(I hope to make my point clear, English is not native for me and Google Translate does not always help ;) )

[flybayer]

Cool, totally understood! :)

Prisma will definitely get almost all the focus from us core contributors. And then anyone who wants to use another db is welcome to contribute a plugin for it :)

[jay-jlm]

Hey Brandon, thanks for creating this debate space!

DB fragmentation is a different thing than JS fragmentation

I believe my point of concern was not db fragmentation per se, but rather its effect on fragmentation at the database connection layer inside the app layer. One of the benefits of a solution like Prisma is to provide a unified API for different databases, right now for sure restricted to just a handful of supported dbs, but that is posed to diversify with time. By doing that, Prisma is reducing the effects of fragmentation not by reducing it at the db layer, but by pushing the tech fragmentation further away, out of the app layer and back into the db layer.

people are still going to use other databases

For sure peeps will take your stuff and do all kinds of things with/out of it. ("l'enfer c'est les autres" for the French heads out there 😉)
The point here - I'm sure you'd agree - is what Blitz will to do, ie, how it moves to position itself as a solution - specially in relationship to other solutions already out there - and to what subset of users and use cases it is tries to optimize for.

This question of finding a project's "soul" or its "claim to fame" reminds me of you citing Rails as an inspiration for Blitz and it (Rails) being an approach that was missing in the JS ecosystem. People coined the term "the Rails way" to highlight the fact that Rails is - first and foremost - an opinionated framework. Sure one can use Rails with almost anything, including all those databases you cited, which is however quite a different thing than Rails going out of their way to support those use cases at platform level.

So I hope it is at least a bit more clear why when I hear that Blitz is making Prisma more of an optional component, it kinda feels to me a bit like Rails 3 having announced official cli support for both Firebase and MongoDB as an alternative to ActiveRecord 😵😵
... maybe I'm not the only one that doesn't quite imediately get it?

I think you already responded to that by calling it a "loose opinions" approach. So maybe what I am missing is that I haven't yet heard why loose opinions is viable or even a better approach than a "strong opinions" one? Or why Blitz chose this approach?

It definitely could help grow a user base, just like offering 10 flavors of ice-cream helps to sell more ice-cream than just having one.

But does the extra luggage introduce complexity into the platform?
If it does, how does that play out with Blitz's original pitch of simplifying development across the board?
What specific challenges the "loose opinions" approach brings along?
Any role-model projects for the "loose opinions" approach that we should know about?

These are some of the things I am asking myself.

[flybayer]

Great points, I really appreciate your perspective!

I think the main motivator of loose opinions is to intentionally be less opinionated than Rails. With Rails, you are cruising for a bruising if you go outside the happy path. So I want to strike a better balance where you get all the initial startup benefits of defaults while also being able to blaze your own trail without hinderance.

I think this is especially important with the JS ecosystem which values diversity so much. I never used Meteor, but from what I've gathered it was as opinionated as Rails or even more so, and I think that was one it's failings.

I'm quite happy for the Blitz codebase to be more complex if it means more people can use and love it. This doesn't match directly here, but in general I think frameworks should do the hard work that everyone else wants to do but doesn't have the time or skills for. A good example is offline support. I'd love for Blitz to have built in offline support one day!

[ryardley]

Prisma providing persistence access to multivariate databases with SQL like semantics may seem like a good thing to leverage off and for a class of applications it probably is. However Prisma demands a relational data structure and a SQLish database yet the data being persisted in Blitz apps will not necessarily always be relational whilst the persistence store may not always be a database. In Blitz applications, data could be persisted to diverse places such as cloud storage like an S3 bucket, a client-side datastore like Redux, an event store via a queueing mechanism that backs a distributed system or it could possibly even be a peer to peer blockchain. I don't think prisma have any plans to support all of those usecases but I think we could re-architect Blitz to do so and this should be explored a little more in my opinion.

When fleshing out Blitz, the architecture was partially based on some of the ideas within Clean Architecture which considers persistence to be a "plugin" to the architecture. This is actually a good idea.

If we want to follow through on the promise of that architecture, (and I think we should) Blitz should actually probably allow developers to build out a persistence interface so that "UseCases" know nothing about how data is being persisted and consider persistence to be a plugin. If Blitz does this correctly then Mutations/Queries become ultimately completely isomorphic, and should have no environment dependencies/assumptions, whilst the database can be swapped in and out for any slice of the app as it is just an IO device.

There are several advantages to this:

• The Application business rules are completely captured in Resolvers and those rules are independent of persistent baggage
• Resolvers can run anywhere which means the application can extend itself to any environment - it can run its logic any where JS can run - on the client, in React Native, in a monolithic environment, in a microservice environment
• Persistence can be anything that can store data
• You get a uniform universal data structure that represents the data in your entire app.
• Resolvers are then also highly testable because you need not have a database running to test them and tests run more quickly.
• Different persistence functions can point to different storage mediums based on app configuration
• It would be possible to evolve the underlying structure towards an event driven message passing model which would mean you could build things like realtime messaging apps with Blitz

Some of the tradeoffs:

• You need to write adaptors to get your entity data in and out of your resolvers.
• You cannot derive your types from the database. (However you know the types you need in your resolvers and can leverage TypeScript to match those types up and manage ORM impedance)

[flybayer]

I love all the benefits you list here, but I have no idea how to make that a reality 😅

[ryardley]

Offline support would be quite possible too by the way. I have a bunch of ideas for how to do this been meaning to throw up an RFC thread.

[flybayer]

Yeah which would be awesome!

[niklasgrewe]

any news on it? i like the benefits too, specially offline and realtime support. It would be nice if Blitz apps would eventually support these features. These are often requested features that I can also use well 😅