What's the best practice for connecting to an SQL database from Vercel/Next.js serverless functions? I've seen a few options commonly mentioned:
Create a new direct database connection in the serverless function. This has important drawbacks:
Connection pooling: every new invocation of a serverless function would create its database connection, which could quickly overwhelm the database
Security: the database has to be publicly exposed since Vercel doesn't support static IPs or VPC peering. This unfortunately is deal-breaker for any security-sensitive application (fintech, healthcare, education, etc.) and SOC 2 compliance
Add an intermediary service that receives HTTP requests and proxies it to the database
My understanding is that this is a common thing people do? How does this work?
Use a vendor-specific solution, like the Prisma Data Proxy product (requires using the Prisma ORM) or AWS Aurora Data API (essentially an out-of-the-box version of the second option, now deprecated)
Trying to understand what the "best practice" solution to this problem is — have others deployed solutions they're satisfied with?
For personnel blog application should be okay to connect your edge function direct to database. Unless, this small website becomes super popular.
Eventually, For your application hosted on edge, another API endpoint is needed. It can be REST API or GraphQL does not matter. What matters is that, at the front this endpoint will accept loads of request from your edge functions (nodejs applications on vercel/netlify) and at the back, it will communicate with database, pool the connections and caching so on.
You can add nginx load balancer in front of that API endpoint to make it scale.
There are tons of options to engineer it
Related
I am having trouble understanding how to use a microservices model. The idea of a microservice is that I have multiple local servers, each serving a different port. Connecting to these local servers can be easily done locally (e.g., using an Express hosted website). But if I am using a frontend application, such as React, how am I supposed to call the different APIs.
The only solution I can seem to think is to create a subdomain per API, but this seems far-fetched and impractical since I would need to create a lot of entries inside the Names Server (e.g., Cloudflare).
If I am using an application like Apache or Nginx, is there a way to publicly access the APIs using a single domain? Or using subsubdomains such as api1.subdomain.domain.com, api2.subdomain.domain.com ... but without adding each of these subdomains to the name server?
An alternative I can think of is creating a public API whose job is to connect to local services, but this seems to defeat the purpose of microservices.
I can't find anything online and all tutorials always use localhost which does not work in production code.
Thanks in advance!
You should research API Gateways / Edge-Services.
Personally, I like hosting the containers for microservices in Kubernetes and forwarding all traffic to *.mydomain.tld to the kubernetes cluster and configuring the load balancing (in this case: which subdomain should be routed to which service) there.
I currently have an Electron ReactJS application on hand that uses CouchDB as its backend for syncing and real-time updates. I have been tasked with "porting" the backend of this application to an existing webserver. The goal is to use the existing permission management and business logic implementations. At the same time the intent is to refactor the data structures as the data is heavily relational in nature. That said, personally, I would keep the app on CouchDB as it full-fills the main "offline-first and real-time" requirements and just add the missing authentication and permission layers, but management wants otherwise.
The port would be using an existing web server (running Play Framework with Scala) and a relational database (MySQL). I have been scavenging the web for a good existing solution. The "simple" solution that came to my mind sounds tedious and like I'm reinventing the wheel. My idea was to create an API and on top of it also send real-time updates to the users to which a change is relevant via web sockets. For state management on the client I would use Redux + Redux Offline. While this would work, this would require a lot of manual wiring of CRUDs on the backend server and the according requests and mutations on the client.
I have taken a look at AWS AppSync, Meteor.js and Apollo. AWS AppSync sounds like exactly what I could use, but it relies on the database being accessible to it, which is not an option due to my DB instance being on premise. From Apollo, the client part sounds like an option I could go with and then use Sangria on the backend. I suppose I could also drop the idea of Redux and use Apollo's "local state", although this requires more thought as I'm not familiar with it.
All of the latter solutions involve GraphQL. While this would still require quite some work on the backend, the communication itself between the frontend and backend would be simpler to handle.
In my case where the use of an existing backend server is a must, are there any more elegant solutions for offline-first collaborative real-time apps? Am I missing something?
I am new to web development, and have seen posts such as these . If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
You're probably going to get a bunch of conflicting opinions on this. My personal opinion is a web service in front of your database makes sense in some scenarios. Multiple applications connecting to the web service instead of directly to the db gives several advantages, security, caching, etc.
That being said, if this is just a single app then most of those advantages disappear and in fact just make things more complex for you. You're going to have to setup your web service for the db as well as your actual code.
If one is using AWS and is connecting to an AWS rds instance through Node, is that still considered a direct connection as opposed to a web service?
No, if Node.js is running on a server or in "serverless" containers (e.g. AWS Lambda) that is not a direct connection. That is a web service, and that's what you want.
A direct connection means the app connects to the database itself... but that requires embedding credentials in the app.
You do not want to embed anything in your app that you would not willingly hand over to an arbitrary user -- such as database credentials and API keys -- because you cannot trust that the app won't be reverse-engineered.
You should design the app in such a way that you would have no security concerns if the entire source code of the app were exposed, because knowing everything about the app's internals would give a malicious actor no valuable information. How? The code on the server side (e.g. in Node.js) should treat every request from the app as potentially suspicious, untrustworthy, etc., and validates every request to do anything.
This layer of separation is one of the strongest reasons why you never give the app direct access to the database. Code running in a trusted place -- your web server/API layer -- needs to vet every database interaction. This topology also decouples the app user from tying up resources on the database server when not actually interacting with the database, which is far less practical with a direct connection.
We're developing a cloud based web application for customer management. One of the main goals i the capability to connect to different local applications on the customer endpoint.
As example, we don't want to have a customer database in out application, the customer should be able to search within his local ERP system right away.
What we need is not much. Only a client on the customers server with access to the local SQL server as well as the COM model.
But as webdevelopers and mainly going with PHP the question came up, what technology we should use?
I've got two approaches in mind:
NodeJS
Lightweight, Javascript and with the Express and winole32 extension we should have everything we need. But the deployment and installation as a service seems to be a bit wacky.
C# .Net Web API
Also a good approach I guess since the client servers are allways windows. But is there a way without IIS?
Or do you have something completely different in mind? It should be very fast and compact. So its basically just a RESTservice that can be deployed with ease.
Thanks for your inputs and thoughts.
C# .Net Web API Also a good approach I guess since the client servers are
allways windows. But is there a way without IIS
It is called OWIN and it is properly documented (web api self host is a good keyword) and works like a charm. Using that on various services to expose an API into the service.
Could someone please explain to me in a simple way, what is a web service?
Please correct me if I'm wrong. I have a DB hosted somewhere in the web, and I want to perform DB transactions from a desktop application as well as a mobile application. Can this be done through a web service ? Someone mentioned it to me and I wanted to make sure this could happen.
Here's a good explanation on Wikipedia.
A middle dynamic content processing and generation level application server, for example Ruby on Rails, Java EE, ASP.NET, PHP, ColdFusion platform
The middle tier of a 3-tier application is often the web service
i want to perform DB transactions from a desktop application and a mobile application, can this be done through a web service ?
This is Exactly what a web service is for.
A web service allow you to create multiple front ends if needed, and serve your database data to all of those front ends. You can also open up the API and allow third party developers to access the web service and thereby access the data of your application in a controlled environment.
It's considered a better practice for larger applications to access a web service or a middle tier rather than directly access the database.
In your case, a web service would involve setting up your DB behind a web server that listens for incoming requests, performs the appropriate DB operations, and returns whatever data is appropriate. Then, your desktop and mobile applications could send a http request and the DB would respond appropriately. This would let all your applications access the same DB.