craigmulligan / nawr

Serverless SQL databases on demand
9 stars 0 forks source link

Some questions #28

Open michael opened 3 years ago

michael commented 3 years ago

Hey this looks like very promising work. Do you think this can help me here?

https://github.com/vercel/vercel/discussions/5696

Since you were working with AWS Aurora Serverless, did you find a way to connect a DB utility to the DB hosted on Amazon? I couldn't figure that out, and it's important for me since I create my migrations just "by hand" and collect them in an SQL script.

To call RDS Http API from Vercel, is there any setup necessary (like allowing public calls?). And how do you ensure that your DB cluster is "close" to Vercel's infrastructure. Like so that you don't experience delays when accessing the database.

Thank you! I'm glad I found someone that has done this integration already. Curious about your experiences with it.

michael commented 3 years ago

Seemless local development workflow against a local db via the RDS http api.

How did you do that? Like you implemented an RDS http api compatible service that connects to a local db?

craigmulligan commented 3 years ago

Hey Michael,

Hey this looks like very promising work. Do you think this can help me here?

Yes, it is supposed to fill that exact use-case. This was an experiment in giving you the vercel workflow (branch deploys, serverless etc etc) but with an sql database + workers.

I think the concept has legs, but I ultimately stopped working on it for a couple reasons. 1. I fell out of love with next.js. 2. My app didn't need 'serverless' scale.

It was working quite well, but I haven't used it in earnest in production. You are welcome to give it a crack and contribute, but my current recommendation for this type of thing would be using supabase as described the link you sent. I think they have branch deploys in their roadmap which would realize most of what this project is trying to achieve.

Since you were working with AWS Aurora Serverless, did you find a way to connect a DB utility to the DB hosted on Amazon? I couldn't figure that out, and it's important for me since I create my migrations just "by hand" and collect them in an SQL script.

You have to send the statements over http. You can have a look at the client library I'm using it will have more details on the capabilities.

To call RDS Http API from Vercel, is there any setup necessary (like allowing public calls?). And how do you ensure that your DB cluster is "close" to Vercel's infrastructure. Like so that you don't experience delays when accessing the database.

You'd want to pick a region close to your users. The vercel endpoint hit near the customer as it's globally deployed but the call to the db might have some distance to travel depending on the request.

How did you do that? Like you implemented an RDS http api compatible service that connects to a local db?

Yeah exactly except I didn't implement it, Take a look at the docker compose file in the repo, it'll have details on where the rds compatibility layer comes from and how the dev workflow fits together.

Hope that's helpful!

michael commented 3 years ago

Hey there! Thanks a lot. I get a much clearer picture now.

I think the concept has legs, but I ultimately stopped working on it for a couple reasons. 1. I fell out of love with next.js. 2. My app didn't need 'serverless' scale.

What were the limiting factors of Next.js for you? And what do you use now instead? And most importantly, can you point me to your app? :)

I'm coming to the same feeling that Serverless Postgres is not for me atm. It's much cheaper to run a managed DB instance on digitalocean and scale that up. Also see my considerations here: https://github.com/vercel/vercel/discussions/5696#discussioncomment-284151

craigmulligan commented 3 years ago

What were the limiting factors of Next.js for you? And what do you use now instead?

There is no "app" object in next, which simplifies things if you are making a marketing site, but if you building a web app you want middleware like permissions. You can use a custom express app for next but then you have to opt out of the vercel serverless deployments. Also I found testing quite difficult, I want to use things like supertest, and have an express-like app that I can give some mock objects eg. const app = new App(mockEmailService, mockPubsub) etc etc. I found that I was constantly having to use jest.mock instead of regular dependency injection. So just generally a lot fair share of dx issues.

And most importantly, can you point me to your app? :)

Unfortunately it's still in closed beta, but it's an app for accounts so it's pretty boring anyway ;).

I'm coming to the same feeling that Serverless Postgres is not for me atm. It's much cheaper to run a managed DB instance on digitalocean and scale that up. Also see my considerations here: vercel/vercel#5696 (comment)

Yeah, 1 sounds reasonable (I didn't realize they offered a pgbouncer frontend as a service). I ended up just running a vanilla express app on a digital ocean, it's been working well until now, but now hitting memory issues and I'm looking to improve how and where I run it as I've figured out what the workload characteristics are. If you'd like to continue chatting about the apps implementation shoot me a mail, I'd be happy to discuss further.