I'm new to React. I'm building a project that uses Django to make a REST API and React to access the api. I have my backend running on http://localhost:8000/ & my frontend running on http://localhost:3000/. My frontend makes api requests to http://localhost:8000/api/v1/.
I found this tutorial to get my frontend running on the index of http://localhost:8000/ for dev purposes. I would still have to have my React dev server and my Django dev server, but I also had to run 'npm run eject'.
Is there any advantage to either of these setups? I don't know too much about 'npm run eject' but since I can't go back from it, is it better off to wait on ejecting until I'm closer to deployment?
edit* - one advantage I see with the latter method, is I can set my permissions as so
REST_FRAMEWORK = {
# Use Django's standard `django.contrib.auth` permissions,
# or allow read-only access for unauthenticated users.
'DEFAULT_PERMISSION_CLASSES': [
#'rest_framework.permissions.AllowAny',
'rest_framework.permissions.DjangoModelPermissionsOrAnonReadOnly'
]
}
instead of having to allow any. This would really only become an issue for deployment purposes too though.
this is what I found on documentation-link for npm run eject
this is a one-way operation. Once you eject, you can’t go back!
If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.
Instead, it will copy all the configuration files and the transitive dependencies (Webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.
You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.
It moves create-react-app’s configuration files and dev/build/test scripts into you app directory.
If you don’t have a need to modify the config or scripts you don’t need to eject. Doing so will prevent you from being able to update to new versions of create-react-app.
create-react-app gives you a fast and easy way to get up and running. It encapsulates the project setup and gives you tools to create production ready apps.
When you run npm eject it gives you access to all config files. This can be useful if you want to edit the webpack setup
so it has it's pros and cons choose what's best for you.
Related
I am working on a project that, among other things, automatically generates Swagger APIs for Python projects. One thing that I have noticed is that the curl text exposes passwords if the API requires those. Since there's no way to mask the passwords as of now (https://github.com/swagger-api/swagger-ui/issues/5025), it seems like the easiest thing to do is to simply disable the curl text so that I can screenshare my Swagger API without exposing my password.
In another issue (https://github.com/swagger-api/swagger-ui/issues/5020), a plugin is shown that can disable the curl text.
However, I'm totally stumped on how to actually import and use this plugin. There's lots of documentation about how to write plugins, and none on how to import them. I can see that I can load plugins using the plugins option in https://swagger.io/docs/open-source-tools/swagger-ui/usage/configuration/, but I don't know how where to put the code.
As Helen alludes to, the answer to your question depends on your setup. However, I would hazard to guess that you will need to configure the SwaggerUI object by running an "unbundled" version of the app. You might think of this as creating a custom entrypoint to a docker container, say.
For example, the link you provide shows suggestions for running a customised version of SwaggerUI. Those customisations are written in JavaScript, so any old HTML page with the necessary dependencies in place which loads the script you write to configure SwaggerUI would answer the question of "where to put that code".
The details would depend on any frameworks you are or are not using.
I currently have a server build process that uses Terraform and deploys a server all from code.
I'm looking for a web UI with forms that I could either populate specific fields and or do API get commands against a VCenter or wherever the server is being built to populate the specific fields. The fields that get populated would be stored as the variables.tf file and when someone hits submit, it would run the actual Terraform command terraform apply to build the server based on the variables. My guess is the terraform binaries would have to live on there so it could run in the background.
It doesn't have to be some super fancy web page, just something that I could potentially make look cool for Director level folks.
Also, I don't want to use TF enterprise, yet. I've looked into a couple of open source projects (atlantis and terrahub) but none seem to be what I'm looking for.
I'm far from a web developer so any help would be awesome.
You can try with SLD
Stack-Lifecycle-Deployment
I think it has everything that you need
It is very intuitive, it has a web interface and a rest api to easily integrate it with the rest of the applications.
I am using reactjs for frontend and Django REST API for the backened. What is the best possible way to integrate both?
which of these two is a good option?
Running two servers for frontend and backend?
or
replacing django templates with reactjs?
Your help is highly appreciated.
Few options here
Django templates with react.
Not my preferred method. Essentially, you are blending django templating and jsx. The benefit here is low over head. It requires little configuration and allows you to write react and leverage the django templating language in the same file. If you need to get something up and running quickly, its a great solution. Have a look at this library https://github.com/Frojd/django-react-templatetags
Using django webpack loader
This will allow you to separate your react code from django code but still keep all your code to one repository. You need to configure django settings to find your react code. Then on your prod/dev server, have your web server point to the directory where your static react code lives or write a django url and view that will serve the react apps index file. It will be located in /static/ after you configure correctly and run python manage.py collectstatics. Benefits here are that it keeps the code to one repository but still isolates the python and javascript code. This is a middleground solution of the three. Quick note. You won't have react hot reload with this method for development. Here is the library that helps you configure this setup https://github.com/owais/django-webpack-loader
Having 2 separate applications
Similar to what you are doing right now, have a separate react repository, either served by a nodejs backend or deploy the code to a cdn service like amazon s3 and serve the one page app from there. And then as its counterpart, have your django app on a separate server with its consumable rest api (will need to configure allowed cors) . This method requires a lot of operational work: deploying, configuring, and management of 2 separate code bases. If you have the time and resources I do recommend this setup. The decoupling of the 2 apps allows this solution to scale the best
What do you mean two servers? You mean two projects/repositories?
Yes, you can keep frontend in the separate project. It make sence if you have multiple clients for your backend (like mobile apps and web). Different developers can have permission to edit only their repositories. Also it make sence if you are going to use some microservices structure for your project. But more simpliest way is to keep frontend and backed in the same project. Try to check some tutorial about Django+reactjs apps.
our PWA lives here: https://m.quemesa.com and we also have native apps with the same codebase.
However, we are not targeting the Cordova Browser platform (because it does not seem to be officially supported and I can’t see what benefit it adds) so we have to add slightly different code for our PWA compared to our native app builds. For example, In the PWA, we use the pure Google Analytics solution which requires 2 lines of javascript in the index.html.
For our native builds, we use the Cordova GA plugin, so this is not required. In the PWA we don’t need to link to Cordova.js and Vendor.js for exmaple (they get a 404 error). In the native apps we do.
Currently I am manually editing (yuck) the output folder before uploading to Azure for the PWA.
Is there some way to edit the Ionic Build Process so that I can either have 2 versions of the Index and it grabs the one it wants for the output folder depending on the build type OR it can modify the html file at build time?
The current ionic build tool alone doesn't support this.
You could just have 2 versions of index.html and a small script to swap between them and build both versions.
It's also something you could do with a "full" CI build tool. Since you mentioned Azure you could make use of Visual Studio Team Services. There are existing tasks available for npm (to install ionic, run a PWA build) and running command/PowerShell scripts. It may be easier to start off by setting up an "agent" VM with everything it needs to build your app (node, ionic, Android studio, etc) then build your build process up from there.
I use gulp-preprocessto update index.html on build depending on platform targeted. The idea of the preprocess is to generate a target index.html before the ionic serve/build with the exact declarations required for the mode selected, pwa or native. More details on this post "Using Ionic/Cordova app sources as PWA"
This is not a question about writing a web-app Vs a desktop app. It's a question about allowing a bespoke application to run in a browser though use of a custom plugin, effectively using the browser just as your render-window.
QuakeLive does this - it's a C++ application with some extra code to run through a browser. Unity3D and Torque game engines also provide deployment options to do the same thing.
Personally, I'm a bit dubious about the usefulness of such a system. But I'd welcome other opinions on the reasons why this might or might not be a good idea.
Not sure if there's a proper term for this, please edit my tags if there is!
It depends on the application. My background is in medical imaging, but what I have to say would apply to many information system clients:
Pros:
it gets easier to build REST-based integrations between applications. This type of integrations can be used by admins to build integrated portals. (So case ID's from one application can be used to launch another with the right context etc).
ideally, users can install your application themselves, on-demand (depends on context if this is really possible)
Deployment of new versions gets easier. Usually the hosting technology has deployment built-in. In client server environments, this can save a lot of work for the IT department.
You can have a single start URL for PC's and thin web clients (like phones). This makes it easy for users to find your application.
You can centralize configuration for clients. For standalone clients, you could of course centralize configuration somehow, but if you app is web based, you always know for sure there is a server, so you can always use it.
you can offload work that's ineficcient to do locally to the server. (reduce # of roundtrips between client/server).
Cons:
Each browser vendor has its own model of wrapping the native code. There are not too many, but it's definetly extra work.
Your app has to "play nice" with the hosting application. Like when the user closes the browser window, the browser may have prescribed when and how you can ask the user to save.
updates to browsers can break your plugin.
system admins may have restricted installation of plugins, disallowing users to install your application on demand (this happens a lot for activex).
your users may not like that extra code is injected into the browser (there is a lot of malware around that does this)
you don't have the opportunity to update prerequisites before installation
I don't believe really that it's just wrapping existing code in a plugin framework.
Your application won't work anymore when the server is down...