Advice on best practise? - Deploying graphql-yoga server w/ Prisma in production

prisma

#13

Your previous job sounds interesting, @max! (and kind of top secret :smile:) . I think you have definetely enough experience to make sophisticated decisions regarding your webstack.

However i can absolutely relate to you, and have very similar feelings and thougts regarding our current tech stack.

The thing is: We are very dependent on the development and speed + decisions of the graph cool team. I mean you guys are absolutely great, and i admire your work. Without you these discussions would not be possible at all.

But the thing is we want run in production.

A little analogy: If a car producer is building a prototype, they call it prototype and drive it on test courses. In software we call this stage beta.
Since 1.0, we’re past beta, and it was solely Graphcools decision to set this milestone, stating:

Yes you can drive our car (prisma) in public traffic, and it will have the basic features we expect it to have (like steering and airbags).

We do not expect it to have any extraordinary features (like autonomous driving, to keep the analogy). But:

  • it should be usable with a normal database or a DBaaS like RDS (
  • it of course can have bugs beyond beta, but not bugs like i can’t delete things.
  • Things like the memory issue (you cited above), should not happen.
  • Things that worked in framework, do not work in Prisma anymore. I could even bring Prisma into a state
    that was unrecoverable via redeploy and i had to nuke the cluster. (Filed an issue)

Now you can say: “If you run Prisma, you’re on the forefront of GraphQL”, you’re on the bleeding edge of web development in the world" - you should expect this - i must state again, that it was decided we’re no longer in beta. If something has the beta-label we of course expect this.

We had, like you @meep a more traditional framework in use before (Flask not Django, but very similar). Now we’re building a Next.js app and hosting on Netlify, so we already leverage the “hottest stuff”.

In my opinion there is however no way back to REST after GraphQL. As someone also working on the frontend (where my users are!), i must say that it’s a 10x-speed-up, zero-to-one technology, that i would never give up.

Also writing universal apps completely in React, instead of sprinkling React across a traditional template language like Django’s or Flask is not an option neither.

So basically we have three to four options:

  1. Use a a buggy and problematic version of Prisma. Fully trust and rely on Graphcool that they will fix it ASAP. Be like water my friend, in the meantime, and just work around any upcoming issues. I do not know Scala, nor does anyone of my team so we cannot write PRs. (which i would do otherwise). I think this isn’t an option for you neither.

  2. Use AWS AppSync instead. Make your own picture, regarding that. For us it’s not an option. I just love Graphcool and i love their OSS approach.

  3. Write your own GraphQL server. We were thinking about writing our own implementation using Elixir and Absinthe. Personally i’m really not a fan of: Everybody build actually the same stuff, solves the same problems, re- and -reinvents the wheel. We would be solving the same problems that GC is trying to solve - without the community. Then, rather learn Scala, fork Prisma and do PRs.

  4. Use graphcool framework. It has missing features. The API is worse. You have far less control, then you would have with a working version of Prisma. But it is running in production (Cars: driving in public traffic, without major accidents).

For us it’s always: Stability first, features last. So currently after really trying to move to Prisma for a week or so, i’m really in fond of option 4 - until all implementations stabilize and i’m able to make a more sophisticated decision.

I kind of feel far more safe with the framework regarding a production app. I do not want to appear arrogant, but i’m not sure what standards other people have here for their production apps. You come from cryptography, so i assume you will have similar standards. I mean people are running production apps on a framework that cannot delete things.

A word to @nilan and the team: Please do not take this to harsh, and understand us as users. We really want you to succeed with us and our apps. We from Bluepick, and i think absolutely love and value your product, your dedication, skillset and courage to build THE GraphQL database interface. I’m really betting on it. Still, if a good friend asked me, i would never recommend it to be used in production, as of 2. February. 2018, and recommend the framework instead.


#14

@bluepick

Thank you for your thoughts Nick. Very helpful and in line with where I’m at.

As an aside. Netlify looks interesting :slight_smile:

I’m using react + apollo-client + S3 + CloudFront (CDN) for my hosting. My frontend stack has been great and I’m very happy with it. I just need to have a stable server + db.

I’m a solo developer building an investor reporting platform. I had been using the graphcool-framework to build a graphql API. At the beginning it was fast and so easy to get going. I could lock down the data with permissions.

As time went on my interface and data models grew in complexity. This meant creating fairly complex graphql queries on the frontend (in part due to the permissions setup). At the moment it is not possible to return Types inside custom resolvers https://github.com/graphcool/graphcool-framework/issues/256.

As my graphql queries grew more complex, I was having to process and format much of the data on the client-side. It felt like my business logic that should have been on my server had moved over to my react client. This was making it difficult to maintain my apollo-client cache using options (i.e. adding createPost to the allPosts query locally). So I resorted to refetchQueries on the client which means more server/db hits and slower user interface updates (i.e. when you create or delete an object).

So my conclusion is that I’ve reached the limits of what the graphcool-framework can do. I think that the graphcool team have realized the limitations of the current framework and the need to separate out server api from the db graphql api. Hence why the future is prisma.

So with that I started to build a graphql-yoga server which is based on apollo-server so fairly stable. I just need prisma to be production ready.

I have a lot riding on the graphcool team making prisma production ready and releasing prisma cloud.

While my demo product uses the graphcool-framework, it’s in maintenance mode and I won’t be using it for production given the issues above. Going forwards I see two options:

  1. Use graphql-yoga for my server and Prisma becomes stable and Prisma cloud is released. Hosting the graphql-yoga on AWS lambda using apex/up (need to investigate) Failing that one of Elastic Beanstalk, Heroku, Zeit Now or bare metal (i.e. Digital Ocean)

  2. Use graphql-yoga for my server (still using Prisma to generate my types/datamodel) but migrate to an ORM + db i.e. Aurora

I love Prisma :heart: and I think the idea and product is great. I’ve got no idea when Prisma Cloud will be released or whether it will be stable.

The not being able to delete nodes issue #1786 is a major blocking issue for me right now.

The graphcool team have been coy so far about a release date. Given the way they’ve been talking, my guess would be it could be in the next two week or so. But maybe that’s wishful thinking. I imagine they are working on it has fast as possible to maintain the graphcool-framework momentum.

I would really hate to migrate to an ORM and db. It would be my last resort.

If I do I would have gone from using a BaaS to having written a fully fledge server. Not quite what I was expecting but hey I’ve been learning an awful lot in the last 8 months.


#15

We are holding out for Prisma cloud and hoping for docs showing the best way to get Aurora set up as a DB. Even just the right path forward with using Aurora would be enough for us at this point, and we can handle hosting the server ourselves until Prisma Cloud is good to go. At that point, we will feel comfortable moving forward to production. We absolutely love Prisma, it has solved so many issues for us (fortunately we don’t execute any deletes).

I have a lot of faith in the GraphCool team, even if the last week and probably next couple of weeks will be painful.


#16

Dear @meep and @Noah_Davis, thank you for your clear thoughts. :grinning:

As an aside. Netlify looks interesting

They are really incredible, love them.

As my graphql queries grew more complex, I was having to process and format much of the data on the client-side.

Yes i would have used a Gateway in front of it. But then again this is was Prisma + Yoga is supposed to do actually.

As time went on my interface and data models grew in complexity. I think that the graphcool team have realized the limitations of the current framework and the need to separate out server api from the db graphql api. Hence why the future is prisma. …

Yes, exactly my thoughts. That’s why i’m really craving for Prisma.

But you guys really made me rethink it… It feels bad and kind of dirty again to build on outdated product version and start a project with technical debt. In about 8 months from now, we would have to migrate back to Prisma in anyway.

This is what i actually would like to do. I do have a time horizon of 2-3 months until i need something ready for prod. We also would like to use it with Aurora RDS.

By the way: @nilan has already confirmed that this will work, so i’m really confident on that part.

So, if a friend asked me, will Prisma be ready for prod in 2-3 months, i would say: I desperately hope so - but please ask @nilan. :grin::grinning:


#17

@bluepick - I have a horizon of one week. So we are trying to figure out short-term solutions currently. :slight_smile: We definitely aren’t leaving Prisma any time in the foreseeable future, we just need to figure out how to stand up in production for now.

We just did a deploy with Zeit Now, but can’t seem to query our data. Let’s see.


#18

@bluepick Nick what do you think of putting a graphql-yoga server in front of a graphcool-framework endpoint? Only have some admin user on the graphcool side and get all the advantages of the framework without having to manage a prisma instance. This could be an interim solution until prisma is stable.

This would mean a re-write of my graphql-yoga server which I have spent a week creating and testing…


#19

I managed to get my graphql-yoga server working on AWS Lambda using Apex/Up. Posted some of the config files here if you’re interested How to configure graphql-yoga w/ Apex Up to work with Prisma


#20

Thanks so much everyone for this great discussion. It looks like most of the discussed topics have been concluded. Let me just share a couple of thoughts and comments then.

  • For the Prisma API, you should be able to setup this Docker image on Digital Ocean, EC2 or somewhere else, and connect it to your own MySQL database (selfhosted MySQL, AWS Aurora, …). Note that this approach doesn’t use the mysql Docker image. Then you can connect to the Prisma service from your local machine or CI environment prisma cluster add as you normally would.

    Connecting your own DB is currently a manual process that might require some digging. Our continuous efforts to improve our documentation should be of big help here! Besides, we will announce an invite only program for Prisma Cloud soon™, so stay tuned :eyes:

  • Apart from traditional ways to host your own GraphQL Server, I can recommend up (here’s a discount code) or now. We have made good experiences with both. I’ve talked to developers hosting the app server on Digital Ocean as well, but have less experience with that myself. @meep Thanks for sharing the link to your up question, that’s super helpful :raised_hands:

  • The Prisma Cloud infrastructure is running on Prisma, GraphQL Yoga and prisma-binding. We use it to manage public and private Prisma clusters, and everything is running smoothly after small improvements right after the initial release.

  • Deleting nodes should absolutely be possible, I agree :slight_smile: This was a slip up due to our work on cascading deletes - one of the upcoming features. We already merged in a hotfix. In general, we are looking to offer a release channel that let’s you benefit from pending changes for the upcoming release. I will write a comment here once that release channel is set up.

  • There is currently one assumed connection leak in prisma-binding which we’re already examining in detail. I’m open to help with investigations if you suspect something, but there is no other bug I’m aware of regarding leaks of any kinds right now. Please be open minded and take statements from members of the community in public channels with a grain of salt :slight_smile:

  • graphql-yoga and graphcool-framework are not designed to be used together. You might be able to get it to work, but I assume you will run into unexpected road blocks along the way. (also see @meep’s other thread here). I shared more thoughts about similar questions in this thread. Please chime in there if you want to discuss this in more detail, I try to keep that thread as uptodate as possible.

Please let me know if there are remaining points or questions that you’d like to discuss. I am really enjoying this discussion :slight_smile:


How To: Deploy Prisma service to Azure and connect to MySQL DB also hosted in Azure
#21

@nilan thank you for your detailed posted :slight_smile: always helpful and friendly.

I’m super excited by the idea of the Prisma Cloud :star_struck: and would love to get an invite.

Apart from traditional ways to host your own GraphQL Server, I can recommend up (here’s a discount code) or now. We have made good experiences with both. I’ve talked to developers hosting the app server on Digital Ocean as well, but have less experience with that myself. @meep Thanks for sharing the link to your up question, that’s super helpful :raised_hands:

I can definitely recommend Apex Up for hosting. It’s easy to learn and handles all of AWS Lambda such as API Gateway, logging via CloudWatch and Lambda.

There is currently one assumed connection leak in prisma-binding which we’re already examining in detail.

For me this is a blocker. Let me know if I can do anything i.e. testing or investigation. I’m relatively new to Node and have never written middleware. But happy to get stuck in. I worked as a tester for a year on an integrated system.

graphql-yoga and graphcool-framework are not designed to be used together. You might be able to get it to work, but I assume you will run into unexpected road blocks along the way.

Yeah I’ve been thinking about it and I think you might be right. You could pull the original query/mutation off the request and forward them to the graphcool-framework endpoint but the custom resolvers will be more complicated. In my case, I would have to maintain multiple large queries on the graphql server in string format and keep them in line with the schema.


#22

Thanks Max! :raised_hands:

Keep your eyes and ears open then :smiley: I’m hearing there is something coming our way…

I had a similar experience. Would be awesome if you could share a quick step-by-step to get started with up and prisma, feel free to ping me in Slack to discuss this further :slight_smile:

The leak was just fixed. Special shoutout to @divyenduz who was investigating this in detail :muscle:


#23

@nilan just created a quick tutorial on how to deploy graphql-yoga to Apex Up


#24

Thanks @meep - that’s awesome!

In case you missed it, the Prisma Cloud Preview was announced yesterday: https://blog.graph.cool/prisma-cloud-preview-invite-only-c251bebf5670


#25

@sorenbs yep I saw that. I submitted an application and am refreshing my email as we speak :star_struck:


#26

Hey all,

Sorry for the semi-necro, it seems I was late to the party, but I think the discussion is awesome and have some questions:

  1. The recommendations of 'up’
    It does indeed seem like an awesome tool, but I’m personally very wary of using it, seeing as it seems it’s being run by a single guy. This makes it interesting for PoC/prototyping, but not viable for any production apps with future plans as of now. Or did I miss something?

I’m thinking that going with something like aws-serverless-express (if using node+express) is much more robust, but any feedback is much appreciated.

  1. What is the value/need for using AWS API Gateway in front of the Lambda app if the latter is using GraphQL? AFAIK, there’d only be two routes, GET and POST for playground and the underlying GQL API. Throttling? Logging?

  2. I’m a bit confused by the instrumentation choices for metrics/logging. It seems that graphql-yoga has built in support for apollo-tracing, which is the underlying info gatherer for Apollo Engine, correct? Is that the recommended approach here, and what’s the difference between this and Apollo Optics?

  3. Does anyone have any hands-on experience with CI/CD workflows using Prisma and some serverless setup for the app layer? If so, any summaries of experiences with different approaches/providers would be much appreciated.

  4. How would one handle subscriptions if using Lambda? Seeing as the container would shut down after a while, it seems Lambda is not compatible with sockets/open connections.


#27

@jhalborg completely get it. It is just one guy. However I am still using the Apex up platform because TJ is working on it full-time and it’s in active development. He generates a revenue stream by selling up pro for $10 a month with the discount code. Also I would say TJ is not just any developer given he created Express.js and commander.js .

If it helps, I have the following commands setup in package.json for deploying to prisma.

    "deploy": "yarn prisma deploy --env-file config/dev.env",
    "deploy-prod": "yarn prisma deploy --env-file config/prod.env",

I also suspect this is the case but I haven’t tried using subscriptions.

You could setup a graphql-yoga server with docker. I have done that but up has been working so well I haven’t put it into production.


#28

The man is a beast, no doubt here :slight_smile: But even beasts can get sick or walk in front of a bus (knock-on-wood), and then what’d we do? I can’t take the chance on hoping that someone will step up to the plate, and being a startup, we don’t have the resources to focus on that.

I’d do something similar, but was fishing for more concrete CI experiences :slight_smile:

Sure, but I’d prefer to go and stay serverless. After some research, it seems AWS has some IoT offering that could be integrated, so I’ll look a bit more into that. As a last resort, one could always have a separate server or service a la Firebase to handle websocket stuff, but again, I’d prefer not to :slight_smile:

It also got me thinking - Relay “connections” won’t keep the connection to the server alive, will they? Aren’t they more just an abstraction for pagination, but will do separate calls for next/previous page when needed?


#29

@jhalborg
If you could let me know, if you find more concrete CI examples that would be great.

I’m not familiar with Relay connections so can’t really comment on that.


#30

In regards to realtime, this Medium post suggest an approach that integrates with Fanout sounds very promising.


#31

Did you figure out how to go about this?


#32

I’m using Apex Up to deploy my graphql-yogq server to AWS Lambda and have it connect to Prisma host on docker on an EC2 instance which connects to a AWS RDS db. The downside of using AWS Lambda is that I can’t use subscriptions. There’s always docker for that :slight_smile: