I just wanted to try bouncing this idea around to see if anyone has tried this or not, and see if it might work.
I’ve a couple of custom services to insert into Strapi which are essentially going straight to Mongoose. Which makes me think this might be possible.
Essentially I’d like to try and run a website. owered by the Strapi database super cheaply, serverless for example would fit perfectly as I’d get a lot of free invocations on AWS for example. I’m wondering is there anything that would get in the way of me using the CMS admin panel locally (or on a stand-up/teardown basis) and instead hit the Strapi database directly via Mongoose from some Lambdas? Most of my operations are read only so feels like this might be achievable?
The main area I can see as being a problem is writing a user. As I use the users entry in Strapi, but don’t really intend for anyone to use this for API access. Everything else is a custom content type.
I wouldn’t say I would recommend it. Could it work? Probably? Would I bet 10$ on it? Probably not. Good idea though, thinking outside the box. If you try it, let us know how it works
I’d totally not expected anyone at Strapi to “recommend” this approach
So I’ve given it a try since posting and so far it’s working pretty well. I’ve got about 8 endpoints that are hitting the MongoDB database on Atlas underneath, many of these are returning static content for a website.
So at the moment, because a single user will make multiple requests that request that static content, I’ve deployed a single lambda for primitive get requests, that has a basic router in there. The advantage of this is I can cache my MongoDB connection between invocations and reduce cold start times. If/when site traffic picks up I’ll split these functions back out. Also planning on using Gatsby or similar to pull out the static content from Strapi whenever it changes (using a Webhook to a GitHub pipeline) and that’ll reduce my dependency on this routing Lambda.
Regarding running Strapi locally - that works for me. But actually there’s someone else who needs access who isn’t as technical as me. So I’m planning on deploying Strapi to EC2 - but it’s going to sit in a turned off state by default. I’m planning on an API Gateway request triggering a Lambda to spin up the EC2 instance, and a redirect to the actual Strapi IP. This might take a couple of minutes, but that’s not a problem in this case. Hope to hack a similar spin down the EC2 lambda into the Logout of Strapi somehow - not worked that one out yet.
But basically I’ve got a site kinda working, costing me the price of an S3 bucket so far. So not too bad!
@IPWright83 I know this is conversation hasn’t been active for a while, but I have a very similar approach working pretty well. We deployed our Strapi instance to a Hobby Dyno on Heroku so we pay a small monthly fee for that. Then we deployed our AWS lambda functions that connect to our MondoDB instance to return whatever data we need. With this approach we get a couple of benefits:
Use Strapi admin so that less technical users can update data
No need to pay for a production Strapi instance to be available for scaling
Cost effective pay for use Lambda functions that are scalable
Good idea though, thinking outside the box. If you try it, let us know how it works 