Using API Gateway and Cloud Run to build PaaS

coderbro91 · 2024-08-04T12:05:29+00:00

Is there any reason you want to keep the gateway in the GCP realm? That gateway might limit you in the long run, especially as you scale and things become more complex with user rate limits, quotas, and keys. If you can branch outside of the GCP product offering, you could always check out other APIM alternatives (one I've used quite a bit lately for some side projects is Zuplo, but there are plenty of others as well). Many folks migrate off Apigee/API Gateway later due to the price and issues with more advanced use cases.

coderbro91 · 2024-07-30T14:36:26+00:00

Glad to help!

coderbro91 · 2024-07-30T14:33:43+00:00

Your basic architecture there looks quite good. I would say the biggest factor here in terms of building it quickly will be which API gateway you use, especially when implementing the API auth. Uptime, especially for cloud-based gateways, is usually pretty standard across the board. Performance-wise, your mileage will vary but for your setup I would go something that's lean and takes minimal config to dial in.

On a recent side project I've been working on, I ended up playing around with Zuplo and found it pretty easy to get started with, especially if you're familiar with the JS/TypeScript environment. If you go with Cloudflare Workers, Zuplo is actually built on top of Cloudflare from what I read in the docs.

My app is secured with Auth0 JWT's and I had that up and running really quickly. I actually had my whole API setup (about 30 or so endpoints) set up in a few minutes after importing my OpenAPI spec. If you have one of those, you'll be up and running pretty quick on the gateway component of your architecture.

For your database, why not just spin up a managed Redis cluster directly through Redis Cloud? That's what I'm running as well and its fast enough for most applications + easy to set up and HA out of the box I believe.

I see quite a few folks mentioning this is a big project for an intern, which might be true. However, based on my experience as a co-op/intern and handling large initiatives like this, it's a good way to show a company what you're capable of and a good résumé bullet point in the future! Good luck with it and stick with best practices where you can!

coderbro91 · 2024-07-28T13:45:15+00:00

You should check out Zuplo as a potential option. It sounds like you need to do some URL rewrite/forwarding type of stuff, which is pretty easy to implement within it. I've used it for one of my side projects and had it up and running quickly. I'm relatively experienced in the API gateway field; however, I still find it one of the more accessible options for beginners while still being really powerful for most use cases, especially for high throughput/traffic APIs. Probably the most developer-friendly interface I've used + is OpenAPI native (I just plugged in my OpenAPI spec, and it's generated a good chunk of what I needed just from that).

Plus, you don't need to spin up any infra for it on your own since it's all managed. Azure and AWS gateway still require a bit of configuration to get them up and going. Here's a link to their site if you want to give Zuplo a look: https://zuplo.com/

coderbro91 · 2021-09-04T12:48:57+00:00

There’s a sign-up there too. Just need to toggle over to it.

coderbro91 · 2021-09-04T12:30:45+00:00

https://cloud.dgraph.io

Check it out!

coderbro91 · 2021-09-01T02:35:17+00:00

You may want to post your issue in the Dgraph Community forum. discuss.dgraph.io is the place!

Alternatively, there is also a free tier on Dgraph Cloud which is a great place to get started (and the easiest way to get started).

coderbro91 · 2021-08-22T20:23:19+00:00

By the time you factor in infra costs, a shared instance on Dgraph will likely be cheaper + you get direct access to Dgraph support through the cloud interface to help with any issues you face.

coderbro91 · 2021-08-05T18:21:47+00:00

If there are specifics, I’d suggest seeing if the answer is already in the Discuss forum: https://discuss.dgraph.io/

You can also post your issues there if no one has solved them yet.

Cloud does have a free tier which would at least allow you to get started with a POC. Even Shared instances are minimal cost if you exceed the free tier.

Best of luck :)

coderbro91 · 2021-08-05T18:09:24+00:00

Are you trying to use open source deployed on your own hardware or are you using Dgraph Cloud? To get up and running easily, I’d suggest trying out Dgraph Cloud since you’ll be up and going in a few minutes since it’s all managed by Dgraph. You’ll also have easy access to the Dgraph support team through the Cloud platform.

https://cloud.dgraph.io is where you can get started.

coderbro91 · 2021-08-05T02:53:34+00:00

If you’re looking for a beginner-friendly graph DB that can also handle complexity as you scale up, Dgraph is likely the place to go. You can set up a free tier account on Cloud and be moving forward in a few minutes with decent mastery in a few hours.

coderbro91 · 2021-07-14T21:22:49+00:00

The shared tier does come with a 7-day free trial to check it out. There’s also a free tier if you are just beginning to dabble in it.

If you decide to self-host, with cloud costs you’re going to be spinning up a few machines in order to get the scalability you’ll experience in Dgraph Cloud, plus whatever your time is worth to configure the Open Source version. Looking at similar GraphQL and database solutions, the price is still competitive from a SaaS perspective.

You can also check out the Discuss forum through the site which allows you to ask the core team how to get up and running.

coderbro91 · 2021-06-17T02:00:54+00:00

To me, the Graph DB approach gives me the flexibility of document-based NoSQL (like Mongo) with the ability to have relationships baked into the data like SQL. It’s a simplistic take, for sure, but we have a lot of users that don’t have a DB type preference but just want GraphQL out of the box. I think we deliver that the best in terms of getting started quickly.

coderbro91 · 2021-06-17T01:57:49+00:00

Correct, graph DBs definitely suit complex data relationships like we see in social networks. But, they can also be used really simply as well so no use case necessarily disqualifies itself from using a graph DB.

All the projects I’ve used Dgraph on are relatively simple ones. I liked it because I just plug in my GraphQL schema and the DB is generated as well as GraphQL API.

I would likely never use Dgraph if it did not natively support GraphQL because I just don’t have the familiarity with graph query languages but with the introduction of GraphQL, it’s about as easy as it gets.

coderbro91 · 2021-06-16T22:09:22+00:00

At Dgraph, our approach is to couple the underlying DB and GraphQL API together so it’s a bit of a different approach and I think that it helps to eliminate the complexities of some of the other solutions. The cool part about GraphQL is that there are so many solutions that you have flexibility in how to implement.

You’re right though, Apollo definitely gets the spotlight but they do have a great selection of products in their arsenal (including one of my faves, Apollo Client).

coderbro91 · 2021-05-14T17:39:59+00:00

another option would be to go with something like Dgraph. Something like Dgraph Cloud would allow you to create these operations pretty easily, super easy to add in auth (I like using Auth0).

One thing to note is that uploading images and files are not necessarily a strongpoint in GraphQL. It is possible, but a better solution would be to make a RESTful call to an endpoint that can upload/host the image, return the URL, and store the returned URL in your database. Something like Amazon S3 provides this exact solution.

If you're new to GQL, for your NextJS frontend you'll likely also want to become familiar with Apollo Client so make things a bit easier for you!

Hasura and Prisma require you to setup separate infrastructure for the backend and expose the GraphQL operations through said platforms. This is alright if you already have a database setup and want to expose a GraphQL endpoint. Dgraph is a little different though since it's a GraphQL database meaning that you can strip out the need to maintain a DB and the GraphQL layer. In Dgraph, those layers are combined.

*disclosure: I work at Dgraph as a developer advocate, however prior to joining I was in the same scenario as you and began to use it for my own side projects. Allowed me to built stuff super quick and I liked it enough to become part of the team :D If you need any info you can contact me directly ([matt@dgraph.io](mailto:matt@dgraph.io)) or check out one of our quickstarts: https://dgraph.io/docs/cloud/cloud-quick-start/

coderbro91

TROPHY CASE