I am currently diving into the world of Svelte(kit) and I am at the point where I need some help with my decisions.
I will use Flask for the Backend so I tried to serve Svelte from Flask (like in this Git) and for the start, it looks fine.
But i prefer Sveltekit over Svelte, so i tried to serve Sveltekit in the same way as Flask, but I only got "%svelte.head% %svelte.body%" text on the page. What do i need to change?
Why serve Sveltekit from Flask instead of Svelte? For example, i do like the Routing in Sveltekit more than in Svelt. But I don't see the Point to use Endpoints while I could fetch the Flask API direct from the .svelte Page instead of fetching to the Endpoint to fetch then to the Flask API. Or what's wrong with my thinking?
Svelte vs svelte-kit
What you seem to be missing is the difference in svelte and svelte-kit.
Svelte itself makes it easy to write reusable fast and small components. These are independend of any server components. Svelte-kit builds on top of that, to create a full web framework, with potential server components.
In practice that means it provides multiple adapters to deploy a web app built with it to different places, such as netlify, as a express app, or just as a set of static html files, for github/gitlab pages.
For all adapters that are not static solutions, using svelte kit also adds the option to have server side rendering, which can often result in a better user experience.
Svelte-kit Endpoints
Your question about endpoints ties into that. The reason why you would have something to gain from making these endpoints from within svelte kit is twofold:
In your specific case, javascript/nodejs are usually faster then python,
and more importantly, if the endpoints are made with svelte kit, they can be used as part of the server side rendering procedure.
Since everything is happening on the same machine, that can dramatically speed up the whole process.
There is also the aspect that having services with different languages interact can be a large cognitive overhead, and the dtos you are transferring can be difficult to manage.
Approaches
If your existing server component is small, or still in the middle of being built, its probably a good option to switch to svelte-kit entirely, for the resulting speedup, simplicity of only working in one language, and a lot of convenience features that svelte-kit affords you. For that option you would have to familiarize yourself with svelte and svelte-kit a lot more though.
Here is some documentation by svelte-kit on endpoints as well as hooks which are very handy for managing user state.
Endpoints are fairly simple, so as long as you have a good grasp on what you are achiving in them, and some javascript/nodejs knowledge, it shoudln't be too hard.
If your existing server component in python can not be rewritten for a svelte-kit app, because of some unavailable dependencies, or because it's simply too large, you do still have the option of deploying the svelte-kit app as a static page, and then making direct requests to your python based service.
There is also the option of using svelte-kit endpoints as a proxy to make requests to your python service. This strategy fit's more into a microservice architecture, or if you are only making a new frontend for a existing backend application. Still, under the right circumstances a good option.
Related
I am currently creating a website hosted by Django. I plan to use React as my frontend framework. I have done some research on putting them together but most say that I should go for the SPA model and have separate web servers for frontend and backend. The problem is that I wish to use apache as a prod server with django and avoid having 2 separate servers. I have read about the hybrid model and having django serve static files with react.
My Biggest concern is security as I have already setup apache for security and I aware that node.js is somewhat insecure.
What would the best approach be. The separate SPA model or the hybrid model.
I'd say it's okay to go for hybrid model if the project is small and you are the only one working on it and you only want to make things done. I think it's kinda messy to create apps like this unless they don't really worth the time.
But if it's a big project and more than one developer is working on it or will work on it then i highly recommend going with separate web servers one serving frontend app and one django app.
Also note that you don't really need 2 different servers. You can use one server for both and use 2 different which is still not necessary and you can use one web server to serve both.
And security not something that different models can cause to downgrade or upgrade. It's up to you to configure the server and write both frontend and backend apps secure enough to do the work for you.
There are more than one web servers that are as secure as they can be and they work with both django and react pretty well. I used nginx many times to host both django and react apps and i had no problem causing by nginx itself whatsoever.
And for last piece of advice if you will; Creating good quality apps requires a lot of time and energy, working with different technologies that do really good for what they are made for and if you are planning to be a really good developer you should come out of your comfort zone and adapt with new technologies that comes out and they are coming out pretty rapidly which requires you to learn constantly and do things in way you are not used to yet and making things work even if they doesn't seem to be good together at the first look.
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.
Am I missing something?
But I am really not getting the rationale behind most online blogs and tutorials suggesting to use a base Django template to render a ReactJS bundle (bundled from webpack).
In my mind, the point of using Django Rest Framework in the first place is to completely isolate the frontend from the backend and have something like Nginx serving an html file that would import the ReactJS library (like any other stndard html/js project). The ReactJS layer would then get or manipulate data solely through the DRF REST API.
It is like most developers treat ReactJS as a completely novel beast, when it can be simply treated as standard JS (with added steroids) that runs on the browser.
Can someone therefore explain to me what are the advantages of using the methods depicted by blogs such as Jonathan Cox and Owaislone ?
On one part, you're right. One of React's principles is to make it function like a Mobile app(that consumes REST API) which also compliments React-Native, so there's not much for the programmer to learn and pick up and can quickly develop an app if they are familiar with React. This way, you'd build the back-end to serve both the web app and the native mobile app without much rewriting or customizing.
Usually, people like keeping their code together, front-end and the back-end if they're just developing for the web. It's a common practice. Since Django is widely used and is also an open source framework amongst a lot of web-developers, there's a big community to develop tools or plugins for it. This way, they'd just have one server instance running and configure the backend to serve just the index.html page, and the routing is handled by the browser.
I, on the other hand, prefer the latter part, work on a team with backend engineers and mobile developers. We heavily rely on RESTful calls for our apps. So we keep our code base neat and isolate our backend from our front-end so each of us can work independently.
It's just a matter of preference really, Jonathan Cox and Owaislone both don't preach about the right way to develop React apps, they just demonstrated one of the ways React can be used.
Also, some backends have a lot of security and need to be configured to allow certain headers for making requests. It could make you look at your computer screen for days while you sit there wondering how to work around the problem and you're diving deep into the documentation for web requests. CORS is one of the problems when you isolate your front end and back end code. It's something that can totally be avoided if Django is serving the files.
I'd say you can go ahead and pick one that suits your need, isolate your React code from the backend if you'd want the back end to work on mobile apps too, saves a lot of time.
I'm fairly new to both Django and Angular. I recognize this is subjective and there are likely many ways to do it, but I'm wondering what best practices people can recommend for laying out such an application. I'm specifically thinking of the case of rich, SPA with the backend being mostly or entirely a RESTful API server, but then I'd like to have a common approach for any apps that serve significant views from Django. (I haven't done enough to decide if the latter warrants using Angular or may be more trouble than its worth).
Specifically:
What are pros/cons of maintaining the front-end code in a separate directory/repository from the backend versus, say, inside a "static" subdirectory of the Django app? In my case I'm the sole developer for now, which has some impact on this decision, but I can still consider myself separate "teams" of back-end, front-end, designer, etc. in the sense that my workflow will put me in one of these roles at a time.
My setup is basically a development machine, SCM in GitHub, and hosted publicly on WebFaction (shared web hosting). I will down the line want to easily grab projects on different development machines, but the primary workflow is just one dev, one prod installation. That said, I'm interested in best practices in real-world projects as I hope a future job may be working with Django.
ADDED: Another point I'm very unsure about is whether the Angular app should/must be bootstrapped by Django. That is, should the front page be served by Django and injected with any data?
PROS:
Can configure URL paths and even API endpoints that change from dev to production, without any alternate config and without these being hard-coded in front-end.
This is maybe necessary for authentication? Unclear to me having not done this yet...
Allows use of tools like the Django debug toolbar app.
CONS:
Couples the front-end to the back-end. What If I want to swap out the latter? What if I want the front-end to work in a sandbox with mock data?
Seems to strongly favor moving all Angular stuff into the Django app layout. At the same time, I don't like having a mix of Angular partials in one place and Django template(s) in another. I am already resolved not to mix NG and DJ templates, as I don't believe much good will come of this.
I also started as solo developer on Django as BE with AngularJS FE. I've put AngularJS files in static folder and everything is fine.
Cons are definitely that you have FE and BE mixed up in one project, but I think that shouldn't matter since you are solo developer. Even if you decide once to hire additional developer (to split FE and BE work) your work wouldn't have any conflicts since one of you would work totally independent.
One of the pros for me is definitely I did entire login process via Django (templating as well) and once login went fine I served rest of the FE (entire AngularJS part).
For Django REST I've used TastyPie. It's great REST enhancement for Django and easy to set up.
I'm writing Django application (social network) and thinking about dividing monolithic project to two projects: UI and API. For example, Django will be used only to render pages, interacting with and taking data from API, written on web.py.
Pros are following:
I can develop and test API independently.
In the future, other UI can appears (mobile, for example), it will require service.
I plan to outsource web UI developing, so, if my application will have two modules, I can provide outside only UI one, not sharing logic of application.
Cons are following:
I'm working alone, and developing two projects are harder, then one.
I will not be able to use cool Django admin panel. I will need to write my own.
web.py is more low-level comparing with Django.
It's like a brain dump, but I will be really appreciated if you share your experience in creating web application with UI module and independent API module.
Update (more specific question, as Mike asked)
What Python framework will you use for creating REST API of social network, which can be used by different client applications? Is using web.py that returns JSON only and rendering it by Django for web is good idea?
Thanks,
Boris.
I've been in a situation similar to yours. I ended up writing both, the UI and the API part in Django. Currently, I am serving them both out of the same process/project. You mentioned you wanted to be able to outsource the UI development, but do hear me out.
In the meantime, I have used django-piston to implement the RESTful front end, but a bit of preparation went into it:
Encapsulate all DB and ORM accesses into a library. You can do that either for your entire project, or on an app by app basis. The library is not just a low-level wrapper around your DB accesses, but also can be for higher-level 'questions', such as "all_comments_posted_by_friends()" or something. This accomplishes two things:
You can call your pre-canned queries from UI views as well as API views without having to re-implement them in multiple places.
You will later be able to replace some - if not all - of the underlying DB logic if you ever feel like going to a NoSQL database, for example, to some other distributed storage model. You can setup your entire app of this ahead of time, without actually having to worry about the complicated details of this right at the start.
The authentication layer for the API was able to accept an HMAC/token based header for programmatic access and normal Django auth. I setup the views in such a way that they would render plain JSON for the programmatic clients (based on content-type), and would render the data structure in HTML (with clickable links and clickable docstrings) if browsed by a human from a browser. This makes it possible that the API is fully explorable and clickable by a human without having to read any docs, while at the same time it can be easily processed by a client just via JSON.
On effect, the database layer I build serves as the internal API. This same database layer can be used from multiple applications, multiple processes, if you wish to do so. The UI views and the REST views were both implemented in Django. They can either be in the same process or in separate processes (as long as they have access to the same database right now).