Prisma1: JavaScript fatigue

[heymartinadams]

As I’m reviewing the release of Prisma2, I’m blown away at the pace of innovation that’s happening at Prisma. Deeply grateful for your pioneering work. Been with you sporadically since the early days and supported Prisma throughout — and certainly still do: recommend Prisma to friends and in a blog post, tweet about Prisma, attend conferences (though sadly missed Prisma Day 😞).

Now that I’m developing a new app, I’m encountering an issue that I’d like to share with you since I’m imagining others might perhaps feel similarly. I’m running into JavaScript fatigue...

• First, there was graphcool (2016)
• Then there was graphcool-framework (2017)
• Then there was Prisma (1.x) (2018)
• Now there’s Prisma2 (2019)
• Now there’s also photon, lift, yoga, nexus, nexus-prisma, graphql-middleware, graphql-import, graphql-binding, prisma, prisma-client-lib, and on and on.

To a junior developer such as myself who doesn’t spend a lot of time in the GraphQL world, it’s hella confusing.

I was just looking at the app I built last year (built, but not released) that uses Prisma 1.x and marvelled how easy it was for me to build it by the end of 2018. Now that I’m studying the documentation of Prisma2 and look at some of its examples (which contains a lot of nexus code which I’m not familiar with), I feel like I’m starting from scratch.

---

Please don’t get me wrong — I’m not complaining. On the contrary, I recognize that Prisma’s is on the forefront of developing cutting edge tech (whoever built Prisma2 in Rust (Søren? Johannes?) did something that’s pure genius). That’s also why I refuse to jump on board to any of the services offered by other companies — though some seem somewhat easier at the moment.

My point here is not to stop... my point is to ask if you might instead consider redirecting a considerable amount of your existing resources to:

• simplify example code & documentation
• streamline offerings

of what’s been developed up to this point.

---

Here’s what I mean by the above points, in greater detail:

I might be wrong, but the code base seems to me now more complex than before. For example, it appears I now have to manually define models in my schema whereas previously I could simply import them using an # import specification in Prisma 1.x (did I understand that correctly?). Somehow, I’m now under the impression there’s more to code, when there’s more joy in less code.

By now, github.com/prisma has so many repos, I don’t even know where to look for examples (say, for Prisma2). Might you consider deleting, hiding, or making private various packages and repos that are no longer relevant (is that even the case)? What if you just had three or four offerings, each of them neatly organized and presented with extensive documentation? Less is more, in my (very limited) opinion. With all these packages floating around (photon, lift, yoga, nexus, nexus-prisma, graphql-middleware, graphql-import, graphql-binding, prisma, prisma-client-lib) I have no idea what most are for.

---

Please take all of the above feedback with a grain of salt. First of all, I’m a junior developer who is still quite wet behind his ears. So this feedback isn’t meant to be instructive from a knowledge background, but just from a junior dev experience background.

I’m also only sharing because I’m deeply invested in the success of Prisma; been pooling all of my resources into Prisma, especially time, and hopefully in the future also money when & once the app finally gets built (by end of this year, wish us luck!)

---

Thanks for your attention, and for letting me share 💌

Feel free to close this issue — clearly it’s not an immediately actionable issue, just a general expression about the direction I‘d like to see Prisma move in this year.

[heymartinadams]

Okay, I think I understand what happened: the newer examples for Prisma2 contain nexus (for code-first GraphQL Schema development), and so the nexus additions have little to do with Prisma2 — and that’s where I got confused. nexus seems more verbose to me than simply typing up a schema, but then again, that approach may cause errors, since it’s not a code-generated schema.

I hope my feedback above wasn’t misunderstood. Really value and appreciate everything that Prisma is doing, and look forward to using Prisma in our new app.

[heymartinadams]

@schickling thank you for an amazing call! 🎉 It’s yet another example — of many — of why Prisma is a company that junior developers (such as myself) can get behind. So appreciate you listening, even if it was just one person’s perspective.

I’ll be learning Prisma2 and nexus now, and hopefully should have a working app ready soon.

Thanks again ✨

[heymartinadams]

So far, have been observing:

• Prisma has been cleaning up its repos (outsourcing the more experimental features / non-core products into prisma-labs; transferring its other open-source libraries to The Guild, etc.). Way to go for focusing and homing in on your core mission 🎉

• The main prisma org still displays a ton of repos clearly not meant for public consumption. Prisma’s important products (photon, studio, lift, prisma2,etc.) — although they’re pinned — might get lost among the many other repositories listed.

• And lastly, there’s been a ton of work on not only prisma2 (now renamed Prisma Framework), but also on nexus-prisma. Eagerly awaiting the development and release of the Prisma Framework and Prisma Studio. It looks like these might be game-changers.

ps: I’m hoping that prisma v1.x will be sunsetted and the prisma2 CLI command will simply be renamed to prisma to properly reflect the new Prisma Framework brand.