I have an existing site using the traditional LAMP stack to present a dynamic website.
My intention is to attempt to port this using serverless techniques. Currently I host this from my own domain, from my own hardware. In an ideal world, I would retain the data onsite but the presentation tier (web farm or equivalent) could run on public cloud, specifically looking at Lambda as an example. However, if it is common / standard / etc to simply use the DF engine itself to assist with this, I could keep the entire infrastructure onsite.
What design patterns are available? What should I be thinking about?
I have a basic DF deployed sitting in front of the MySQL instance, and is able to provide JSON output of my existing SQL queries. This is the start. But how do I combine this with server-side calls to retrieve this data, process it and display it? (i.e. replacing the PHP part).
If I simply swap PHP for Javascript, this becomes client-side and the API calls would be visible to the end-user which I do not want. Or is this acceptable and able to secure it in some other way?
Should I use DF’s own post-processing capability, to do the code processing and return a full HTML page?
I understand the principle of simply publishing out my data (from authorised API token access) in JSON format, which I would like to use. I am mostly stuck on the presentation tier and how it operates with DF.
Looking to simplify as part of this design.
Thanks
@tropicaltwin - what I’ve got aren’t necessarily to the level of practices and patterns, but what works for me.
Most of my apps/sites for work use exactly what you’ve described - javascript on the client side, with the middleware/backend handled by dreamfactory. As you’ve noted, API calls are exposed to the client this way, so you have to ensure proper security and that you’re preventing replay attacks. Dreamfactory gives you the tools for this, just make sure you use a session token and authenticate each user. Of course, if you don’t have users or privileged functionality, then just the API key is fine.
Most users aren’t really looking at code, just a good experience, so lots of API calls in the devtools aren’t a problem in “real life”. Due to concurrency limits (6 calls/domain), you might need to think about how your page loads and how you build up the page though.
Ultimately, I think a php website will always(?) be a bit faster than a fully clientside one, but fully clientside tends to be easier to develop and maintain.
So, all that said, my sites look like this:
- Static file server. All my files live here. You can do this in docker, or Azure has a nice static website pipeline attached to ADO that makes CI stupid easy. You can also just push the files to S3 - whatever you want. Just put the html+js assets somewhere the world can get to.
- Dreamfactory API, running on a server, again, somewhere the world can get to.
- SQL database, whatever is your favorite flavor.
Then the next question is how to build the static files. I did my first couple in plain old JS so I could understand what was going on with all the calls. More recently I’ve become a React.js convert - it makes life very easy, and the static assets that are “built” at the end can be deployed serverless.
I haven’t used lamba in this tooling, but I think it’d be useful if you didn’t want to make all those calls to build the page - you could pull the rendered page from the server without managing the server. If you’re not already comfortable with it, I’d go fully client side and add lamba when you have a need for it. Otherwise it’s just extra overhead.
Thanks for the breakdown @jraiche1 and I think it is along similar lines to myself.
Mostly looking to learn cloud deployment patterns, as I know it from an infra view but need help with joining it up with the code. I am not skilled at JS, but sure I can find / crib together the equivalent logic needed to replace the PHP page, but I prefer to segregate and secure the environment and run it entirely on the backend. Just this time with a DF instance fronting the DB calls.
I would prefer no-one looking at the code. Not only users, but scrapers and other tracking tech to have a harder time than simply loading the page. JS calls I typically only use for styling and / or standardised web-tech frameworks, Bootstrap, etc. I don’t mind this type of content being rendered on the client side. But on a more open web site, I would like to user to simply specify a web URL to access, no authentication required. Does this leave only API Keys to secure? Can I deliver these server side?
I hope, and expect, DF to be capable of doing this.
You’re correct, if you do render fully client-side everyone can see your code. And if you’re open to the world to read, just API keys are fine.
I’d suggest if you’re looking for cloud deployment practice lose the idea of serverless - maybe consider an “managed server” model instead, where you don’t touch hardware or OS, just your code.
My experience is mostly in Azure, but presumably AWS and GCP have comparable offerings.
This would look something like:
- DB (Azure has a managed server in the cloud, HA, backups, and upgrades are all magic)
- Web App (lift-n-shift your existing php initially. Azure has some free options, again, no VM to manage)
Get that running, then shift to dreamfactory instead of direct DB calls; now you’re decoupled from the underlying RDBMS.
IMO, serverless = clientside rendering, otherwise you have to have some kind of server. In general, a server you don’t have to maintain is as good as eliminating the server. If you want a server you don’t have to think about, use Docker or (simpler) one of the web app offerings like I’ve listed above.