- Strapi Version: 4.15.5
- Operating System: Linux (Manjaro)
- Database: Sqlite Currently
- Node Version: 20.9.0
- NPM Version: 10.10.0
- Yarn Version: 1.22.21
Good evening everyone,
I’m going out on a limb here with this. I’m working on a project (personal but with ultimate business intent) and I’m not sure how to approach something. For the record this isn’t a problem with Strapi, just trying to get an idea of how others would approach a programing task/problem.
Onto the problem. Here is where I’m at first:
I’ve coded my frontend nearly entirely. I have logins workings, signup is working. I haven’t tackled payment yet, that’s coming.
One of the major things we need to do is protect our video source. We utilize cloudfront for this with signed URLs.
I understand how to sign the URLs and all of that. I’m just curious if the community thinks this could be implemented into the existing back end of Strapi via custom endpoints and controllers or if this really needs to be it’s own service somewhere else.
I’m leaning towards it’s own custom service primarily because I’m more fluent in python for this sort of thing and I know I could have it built out fairly quickly but at the same time, this is a learning expedition. I’m just not sure if Strapi’s infrastructure is the right way to go about it.
So the way this will need to work is:
- Check user is authorized to watch content (IE paid for it)
- Produce a signed URL
- Send the URL off to the user
Obviously doing this on the frontend isn’t secure at all.
Just curious how more educated Strapi users would approach this.
From what I understand, you have two choices for your backend code: Strapi and Nuxt (here is the doc for Nuxt backend code)
Both are good choices, but I would pick just one and stick with it, because having two backends is rarely a good idea. So If you already started with one, go with that.
So what to consider?
- Which one do you feel more confortable (or excites you)
- Which one will be hosted with more resources available?
- If you use Netlify, Vercel or any other Platform as a Service (PaaS) for you Nuxt code (meaning you only point your Github and they deploy everything for you) make sure you can read the backend logs (often is a bad experience). Because you WILL need to read your production backend code at one point, so be sure you can do it.
- If you plan to do some more heavy processing (like image procesing) on the backend, PaaS usually have a limit in request response that can be very annoying when doing more heavy tasks
- Which one is easier to test (running automated tests). I can tell you from experience that Strapi is not ideal for this, but I don’t know about Nuxt
Hope it helps!
Thanks for the detailed and helpful reply.
When I wrote this I was amateur hour for me with Strapi. I’ve actually dug a huge deal into the docs.
So a few things so far. All of our backend code now sits on Strapi including managing logins, database interactions (obviously), and so I think it makes sense to stay with Strapi in that regard. If I can avoid running two backends, like you said, that’d be ideal.
So I started going down the route of building custom controllers and a custom endpoint. I haven’t finished it yet but I do have a working endpoint that returns some data. I’ll need to add some additional code and functionality to actually sign the URL for the frontend but it’s working nontheless.
At the time I wasn’t quite sure Strapi’s intent as just being a CMS and not really dealing with user logins. To clarify that a bit: is Strapi designed to just be for admin, marketer use and not actually manage end user (in our case customer) logins. I haven’t found a definitive answer to that question but from what I’ve seen, the answer appears to me to be it is supported and seems to do it quite well.
So for now Strapi is going to be the home of our custom code we need to produce the signed URLs. It’s really not that much of a process in all honesty and has so far been fairly simple to implement in node and python. Adding the additional endpoint was also pretty easy in Strapi as well.
thanks again for the response and advice!