Hey guys, I’m using TypeORM for my services, and w...
# help
a
Hey guys, I’m using TypeORM for my services, and works pretty much well. Now, I’m trying to design a solution that can allow me, on my lambdas, to create a connection to the DB only once, and also allow me to have cleaner lambda source code. Does somebody investigated a way to create a TypeORM initialization from a lambda-layer? Or maybe creating a wrapper/middleware that can encapsulate each lambda and provide them a live connection? My goal is to not repeat the
orm.init()
call on every lambda, which also has to keep that connection on the scope.
r
Could you use RDS proxy or the serverless-mysql better?
a
Not sure how the RDS proxy works, going to check it.
I was thinking if I can use middy.
r
What DB is it?
a
I’m using Mysql on RDS.
d
The pain of serverless and rds. The best AWS solution is indeed rds proxy. Middy doesn’t solve connection pooling for you. If your MySQL rds version supports rds proxy, then the proxy endpoint is what you have all your lambdas connect to.
r
As I mentioned, we've used serverless-mysql. Works well to manage the connections in our experience. Written by Jeremy Daly and very well battle tested
d
Haha we also had to use https://github.com/MatteoGioioso/serverless-pg Can’t wait til proxy supports our version
t
These libraries like TypeORM and Prisma need to update to support the data API. The experience using traditional databases with serverless isn't great otherwise
a
Yeah definitely not great, also typeOrm has some sort of memory leak on lambda, my lambda keeps increasing memory usage. :(
a
We opted to just type SQL with slonik sql tagged templates and write a tiny data api wrapper that dispatches slonik SQL statements and parameters to Data API via data-api-client. These queries are throughly integration tested against a live DB, since you can easily run them from anywhere as you don't need to tunnel/VPN into a VPC or make your database public. Side note for our setup: we didn't really consider ORMs for our team, as we decided that we'd rather lean into the power of SQL than learn to use an ORM. Ended up working well for us as Lambdas don't need to be launched in a VPC and we still get to use SQL for some parts of our application. Latency suffers though and we've yet to gather production data on this.
t
Oo slonik looks cool
a
I like
data api
concept, I saw some big companies are using that to have “database as a service”. But I’m not sure if go away from ORM at the moment, my team has been using different sort of ORMs for years (from php to java and js).
a
Yeah, it's definitely not for every team. I wasn't able to find an ORM that had a pluggable SQL execution engine that could easily be used with Data API.
d
Not a suggested solution here - just food for thought. To resolve this serverless compat issue and other reasons, I may have to seriously try https://www.planetscale.com one day.
t
Planetscale on my list as well
a
Yeah, the database branching looks super cool.
a
Whattt, database branching?
I’m interested now. 😂
Ohhh, I want this now.
d
Supabase has sold me extra hard on postgres's RLS capabilities. Now if we had this for Postgres, phew!