I am reading up on the book web scalability for startup engineers by Artur Ejsmont . In his book, he makes a distinction between web services and front - end web servers. He says that front end web servers are for generating actual HTML and serving client's requests.
I have a few doubts regarding front - end web servers after reading through the book that I would like to clarify.
A front end server serves the main page of a website. For every link that requires a full page load, the request is routed to a front end server to serve the page. (E.g serving static files generated from a react build). Also, since frontend html are static javascript and html files, can't they be served entirely from a CDN ?
a web browser can make a web service (API) calls directly without going through the front app servers as shown in figure 1.10 right ? these api calls don't require full page reloads. Also figure 3-13 also shows a client request passing through the front end web servers and hitting the back-end layers. I am slightly confused by the diagrams in the book.
Hope I am making sense. It would be great if I could have some practical examples/scenarios corresponding to the infra mentioned in the book !
Related
So I have a Django backend deployed on Google App Engine. This backend supports an iOS app. In my server logs I can see all the requests coming in and where they were made. It used to be that I would only get requests from Joon/7.** (which is the iOS app name + version). However, recently I've been getting requests from Chrome 72 which doesn't make sense cause the app shouldn't be able to be used on Chrome. Furthermore these requests are creating a lot of errors in my backend because it is not sending an authentication token. Does anyone know what is going on here? Are my servers being hacked?
Looks like someone discovered the URL to your App Engine app. You can use Ingress controls to only allow access via Cloud Load Balancing and then Google Cloud Armor in front to protect that with rules that look like:
has(request.headers['user-agent']) && request.headers['user-agent'].contains('Godzilla')
It is quite common to see all sorts of hits (from what I call spam bots) to an App Engine App. Technically, GCP expects you to use Google Firewall rules to block these. The challenge though is that these bots usually change their IP Addresses frequently or use multiple ones. I don't have a 'perfect' solution.
a) You can try the method by #jeff-williams (I've never tried that)
b) You can also try GCP's firewall rules (I use this but I try to block a range of IPs instead of blocking them one by one)
c) Sometimes I also put my service behind a specific non-intuitive path. This way, the spam bots will only hit the default/base url and then I have a separate service which returns 404 for all calls to that base url
I have searched a lot but could not find any satisfying answer.
I want to know if any IDE provides an environment for web development using Angular and Django. And how to access Django APIs in angular.
please tell me.
I will be thankful for your guidance.
The first thing that comes in mind is Visual Studio Code. It is very versatile and easy to set up for starting web development.
https://code.visualstudio.com/docs/nodejs/angular-tutorial
You have a lot of extensions which can make your life easier in developing by just typing in the search Angular. You'll finde code highlighter, debugger for chrome etc...
same goes to Django, fast easy set up, good extensions and you are ready to go.
I was not familiar with web development at that time. My question was about accessing APIs in frontend. All IDEs and Editors can be used for frontend and backend development.
The main point to keep in mind is that your frontend will have its own server and backend will have its own server that will compile and react to changes you made in your code.
Let's say your frontend server serves on localhost with port:8888 and your backend server serves your APIs on localhost with port 8000
By running both server at the same time you can access APIs in your frontend with backend routes like:
'localhost:8000/login'
localhost:8000/user/user_id
I have a question that is probably more general than django-related development. The background is quite simple:
I am working on a project whose pages are mostly associated with a web application (this is what I am using Django for). In addition to the app-related pages, however, there are quite a few auxiliary pages (like a landing page, a faq page, a contact page, etc.) that have basically nothing to do with the web app.
What is the standard strategy for deploying such a project? It seems flawed to route requests to these static pages through Django. What seems to make sense is running two servers: one responsible for running the Django app and a a separate server that is responsible for serving the static pages (including, perhaps, the static content used by the app portion of the web site) .
What are some guiding principles that should be employed when making these decisions?
It's not uncommon to run Django side by side with a static site or another CMS.
You would need a front end server to route the request to either the static content or a CMS.
There are two common strategies:
Use URL prefix to determine where to route (e.g. example.com/static/ to static files and example.com/ to Django). You would need a front end server to route the request to either the static content or a web app/CMS written in another framework/language (this is configured with Alias directive in Apache).
Put the application server and static file server on separate domain/subdomain (e.g. static.example.com to static and app.example.com to Django). You can do this by configuring a front end server to serve on a single machine (this is configured with VirtualHost on Apache) or as separate machine. In either case, you'd need to configure the DNS to point to your subdomains to the right machine(s).
The former is simpler to setup, but the latter allows you to scale better.
Servers commonly used for front-ending an application server includes Apache, Nginx, or uWSGI, but pretty much any production-quality web server can do it.
In fact Django's deployment documentation (e.g. Apache) would always instruct you to have your static files served by the front end server even in a Django only installations, as Django weren't designed for efficiently serving static contents unlike the front end web servers.
The django.contrib.staticfiles app is there to make it possible for Django to refer to a static file hosted on a different server and easily switch between serving static contents with Django's built-in server during development but with the front end server on production.
I've designed a desktop app using PyQt GUI toolkit and now I need to embed this app on my Django website. Do I need to clone it using django's own logic or is there a way to get it up on website using some interface. Coz I need this to work on my website same way it works as desktop. Do I need to find out packages in django to remake it over the web or is there way to simplify the task?
Please help.
I'm not aware of any libraries to port a PyQT desktop app to a django webapp. Django certainly does nothing to enable this one way or another. I think, you'll find that you have to rewrite it for the web. Django is a great framework and depending on the complexity of your app, it might not be too difficult. If you haven't done much with web development, there is a lot to learn!
If it seemed like common sense to you that you should be able to run a desktop app as a webapp, consider this:
Almost all web communication that you likely encounter is done via HTTP. HTTP is a protocol for passing data between servers and clients (often, browsers). What this means is that any communication that takes place must be resolved into discrete chunks. Consider an example flow:
You go to google in your browser.
Your browser then hits a DNS server (or cache) that resolves the name google.com to some IP address.
Cool, now your browser makes a request to that IP address and says "get me some stuff".
Google decides to send you back a minimal amount of HTML and lots of minified JavaScript in the page.
Your browser realizes that there are some image links in the HTML and so it makes additional requests to google to get each of the images so that it can display them.
Now all the content is loaded on your browser so it starts to execute the JavaScript code, and that code needs some more data from google so it starts sending requests to google too.
This is just a small example of how fundamentally different a web application operates than how a desktop application does. On a desktop app you have the added convenience that any operation doesn't need to be "packaged up" and sent, then have an action taken, etc (unless you're using a messaging architecture, but that's relatively uncommon outside of enterprise apps).
So I have noticed that the docs for various Application Servers (think Unicorn, Puma for Ruby, Warp for Haskell etc) always mentioned something similar to "it is optimized as an app server.” Typically this is mentioned when describing the standard setup of using a HTTP server (like Ngnix) in reverse-proxy in front of app servers.
So my question is: What exactly does the programming of a web application server make it more performant for serving data generated by code v/s HTTP server? Is there any particular engineering trade-offs? Or is it more the case where HTTP servers are optimized for serving files from a disk, and so they're merely trying to say that HTTP servers are not optimized for application code?
First, this really belongs in ServerFault or SuperUser.
But basically, Apache & Nginx strictly deliver static web content. Yes, you can install PHP as a module & it will parse scripts when the page is requested. But it is all on demand. Meaning the program runs only when the page is requested.
In contrast application servers run programs that are active in memory all the time. Which can have some engineering benefits depending on what you want your system to do. So Tomcat or Passenger (for Ruby) run Java & Ruby apps, and are optimized to do it in a production server environment.
Why does Apache or Nginx get attached as a front end? Because at the end of the day Apache & Nginx still are the best tools for simply delivering web content. And have better optimizations & security in place to do so.
So the application server focuses on making Java or Ruby run as cleanly as possible & deliver basic web content. And Apache & Nginx concentrate on the front-end side of web delivery.
As a systems administrator, I prefer to proxy via Apache or Nginx since I already know how to configure & optimize those tools for my use. If I have to learn how to fine tune Passenger or Tomcat, it should only be enough to allow me to get it running so I can place Apache or Nginx in front of that.