As Strapi official docs point:
At the moment, deploying the Strapi Admin interface requires more than 1g of RAM.
Though in my project, I need only some basic actions with the server (like adding and viewing content), and I already do this via HTTP requests to api. So I would like to deploy only the "api" part itself and not admin panel logic. This way I can save resources & money. Is there a way to do it?
Please check Deploy the administration panel and the plugins on another server than the API
You can just delete the build folder. You do not need an admin panel.
Your REST or GraphQL API will work as the way it is.
You can do this only by making big changes to the main module of Strapi, after that you won’t be able to properly manage the permissions system and other main components, you will also lose the possibility of updates.
update
You can just make all configuration and remove web part from hosting
Related
I work in a company where we have many different applications. To reduce code repetition and keep the experience for the users the same across applications we created a component library which is used by all applications.
Now we want to allow the users to switch between applications. Something similar like Google does:
Screenshot of Google Application Drawer
An additional requirement for our "Application Switcher" would be that it "updates" itself. Meaning if we change how this "Application Switcher" looks we don't want all applications which use this Switcher to create a new deployment and be newly deployed.
So currently we use the same header (from our component library) in all our applications. So, my idea was just to simply add a script tag to all the index.html pages of all the applications which should support this "Application Switcher". The Script would parse the DOM, find the header and inject a component for this application switcher. I wanted to host the actual script from a CDN like server and the script tag in the index.html just references this URL. This way we could change this script however we want, and all the applications will always get the latest version.
Now I did a small proof of concept in our environments and solved all the CORS issues but since we were fetching from an authenticated context and the script was also in an authenticated context I always got a 401.
Additionally, we have the requirement, that this "Application Switcher" shows different applications to different users i.e. depending on which apps a user is allowed to access. So, the script itself will also do calls to an "Application Switcher" backend providing it user-specific information.
Now this makes me think that my initial idea of just putting a script tag and fetching from a CDN was too simplistic. Now I'm thinking if it would be better to implement a rest endpoint in all applications to fetch this script. This way I don't have the problems of fetching a resource from an authenticated context from the user's browser and instead can handle all of this in the backend.
So long story short; I feel like a complete noob who just hacks around to get things working (or actually not working) and was wondering if any of the smart internet people out there (who might actually already have experience with this) could give me a hint what would be a clean way to implement this?
I am going to building a very large SPA based ERP SaaS with react.js at frontend which has a really complicated role and permission-based system. I have done some analysis of my application so I realized that I must make a proper architecture of my application so that I shouldn't regret and worry about my application and it's scalability in the future. Mainly I was worried about role and base management. Where I need to switch between different components at first load.
Backend I am working with on this project: Php and node.js
My Exact Problem:
I have about 500+ permissions with 100+ roles in my system. Some roles get only 1 to 10 permissions. This results in switching and showing the only component of that permission in the client browser at the frontend. My main problem is Why should I load unwanted components in the client browser of which users don't have permission to access ?
Problem Example: Admin has given only 3 permissions to Mr.John in their system . Where system contains total of 100 permissions. Each permission results in switching and viewing 100 parent components. If Mr.John has only 3 permissions which should switch only 3 parent components so why other components are sent to the client browser?
What did I want to do?
After authentication, I want to verify the permission and role of that user at the backend and send only the required resources to the client. So that My application size depends upon the role and permission that a particular user has.
To solve this problem what I thought (Not Sure) :
Before this project I have a similar project at PHP without using any complicated frontend library. It was really easy during the development phase. I have worked with React and Vue. But I have never used Server-side-rendering. I thought the concept of SSR could help me so I went to tons of sources and learned about SSR. (Still, I am not sure that the concept of SSR can help me. )
Please Help me to make the proper decision?
What I understand about your problem is How can browser load exact files based on role and permission instead of all files.
Code-splitting is what you want exactly. This is not just React but for all front-end framework(or library) by using webpack
Read official articles
https://reactjs.org/docs/code-splitting.html
https://webpack.js.org/guides/code-splitting/
Maybe entry point of a bundle(webpack) must be simple. After getting a role and permission, the browser has to load components you want. Also, maybe react-router helps you. Or if you consider server-sider-rendering, next.js is for you
We are looking to use KeystoneJS in a large project and we want to be able to customise the Admin panel. There's a nice example of how to do it here, and I've been reviewing this PR to the project. Although the example looks as if it would work for us, I don't understand the logic behind it, that is, what we would need to implement to make it work, what the possibilities and constraints are.
Is it the case that when you use the Keystone NextJS app (which is good for us), if you add a folder /admin/pages the Keystone app will look there and use those custom admin pages instead of the regular ones? I'm assuming we have full access to the rest of the app, the controllers, the DB from these pages as well....
I also noticed that JedWatson notes in https://github.com/keystonejs/keystone/pull/1019 that
Note this lacks SSR support, and I didn't put as much effort into the examples, but it's otherwise (I think) identical in functionality.
Does it lack SSR support just for the admin part, or does adding custom admin pages somehow affect SSR support in the rest of the app? (SSR is the reason we're using next)
Thanks for any info.
There are two api for custom pages, one is pages option in the admin-ui app constructor and 2nd is part of hooks api in keystone constructor.
pages: this one is legacy and only adds custom pages, it does not overwrite the existing list pages in admin-ui it only hides them if not properly configured. usually the Dashboard is visible and all lists are listed there.
hooks: this is new and expected to add more customization options, unfortunately my PRs are stale and they are not the spec keystone core team would want to add. this also does not removes any pages.
admin ui runs as react app built or loaded using webpack config. that is why there is no ssr support. even though the example use a custom admin directory but that not loaded by nextjs component, it is loaded dynamically using webpack server mounting the admin-ui react app
if you really want to have ssr, you can use some learning from closed PRs which were used as POC long ago. but that would be overkill as the admin-ui has many more updates after that.
hooks/pages have access to core limited set of access, there are some access based on React context, provider and consumer hooks. You can use react-apollo hooks as there is already provider wrapped at root of react context. you can also make use of react router hooks, they are upgraded to latest version. it has no access to server side context or controller. (not sure what you meant by controller)
I am working with a team to develop a Google Action for an Organisation called 'Rocket Chat'. Now what we want to do is that, to create one main account under that organisation, where frontend and backend will be hosted and also give access of this account to a few Developers. What will be the most efficient way of doing this?. Any ideas or suggestions on how to do that are appreciated. Thanks.
Frontend is hosted on Dialogflow and for backed we are hosting our fulfilment on Firebase. If you want more details on our setup, please visit here => https://github.com/RocketChat/google-action-rocketchat
The "correct" way to do it would be for every developer to use their own account, and share a project with all of them. This also will allow you to have more granular permissions for each developer.
In addition to having ownership of the project, you may also want to have some processes in place to mitigate potential issues. If everyone uses one project, it's possible to run into race conditions if multiple developers upload the same cloud function. The Dialogflow console also may have issues with multiple editors at one time.
For easier development, each developer may want their own separate prototyping project which gives them full control over the environment, and then have some way to integrate their changes into one master project.
I would appreciate if someone could point me to the more simple direction between Firebase and Heroku.
I'm planning a simple React Native photo app for scientific purposes (take image, save phone geolocation, send both details to database, that's it!).
I need to create a really simple admin UI for the submitted photos+geolocations: view, delete, tag photo (correct/incorrect), download geolocations. Just one user is OK.
Would it be easier me to create the admin UI on Firebase or Heroku? Or if there are already ready-made admin UI's available?
The stack is: React Native, Node.js (+ Express?), MongoDB
And, I'm not creating the app myself, but hiring a freelancer. Maybe they have their own preferences, but I was just interested to know of there's a big difference accessing the data in Firebase or Heroku.
Both the app and the admin UI shoudl be really simple, just bare-bones. I expect the app + admin ui to be created within 100 hrs.
The core capability of Firebase is real time sync of data pushed to multiple clients. It doesn't sound like you need that in your app. You could still use Firebase for what you need, but frankly it sounds to me like overkill.
I think that for your simple requirements you might find Heroku easier and faster.