I have developed a web application using the aiohttp module (the web part) and haven't encountered any issues so far.
Though, when I try to deploy it to my hosting service (NameCheap), I am asked for the "application startup file" (so I guess it is the Python script I run to start the website, in my case name.py) and the "application entry point" (as a hint, I'm given Setup wsgi callable object for your application). I'm clueless about that. I've seen some things about how to use uWSGI with Flask and Django but nothing for aiohttp.
Is there any way to make things work here, or should I get a VPS instead of a "regular" web hosting service?
aiohttp is not WSGI framework PEP 333 and PEP 3333 but TCP socket server.
I know nothing about NameCheap hosting, sorry. aiohttp deployment page provides basic information about aiohttp server deployment.
Related
A web application that generates dynamic content requires two components:
Web Servers - primarily communicate with clients, by handling HTTP requests and responses while serving content.
Application Servers - on the other hand, generally sit behind a web server. If the web server can not generate the requested content via static files, it then reaches the application server to generate the dynamic content.
Software Examples
Examples of web servers include Nginx and Apache
Examples of app servers include Puma and Unicorn
Web servers and application servers work together as components in typical web applications.
Running Rails in Production
When running a Rails app in production using passenger, some options include:
Running Passenger as a stand alone solution
Running Passenger as an app server and Apache/Nginx as the web server
Running Rails in Development
When running a Rails app in development, it is configured to use Puma by default - see Ruby Docs. Puma is an application server. How is it that by default, in Rails, Puma can run the entire web application on its own? There's no mention of a web server like Nginx or Apache in the application stack.
I don't understand how this is possible. Can someone please explain this? Puma has always been an application server, not a web server...
Thanks in advance.
The distinction between a "web server" and an "application server" is rather muddy and has a lot of implicit (and mostly historical) baggage.
Generally, a web server is understood as a software which communicates via HTTP (or HTTPS) to clients and send static files as a response to requests.
An application server on the other hand often does not communicate directly with clients (but instead with intermediate server systems in front of it, such as loadbalancers, proxy servers or well, web servers) and its main function is to respond to requests with dynamically generated content. Application servers sometimes communicate with those intermediate servers using protocols other than HTTP, such as FCGI or AJP.
Often, we will see classic webservers (such as nginx, Apache, lighttpd) used together with an application server such as Puma, Unicorn, Thin, or Passenger. The reason for that is that those webservers are more efficient in serving static files than the application servers which are more geared towards helping the application generate dynamic responses. Also, web servers might be better suited than application servers for buffering requests and responses from clients without using a lot of resources.
With that being said, in the last couple of decades, it became increasingly common to just use HTTP everywhere rather than to use e.g. FCGI internally. Thus, application servers are generally able to speak to HTTP clients on their own without strictly requiring an additional web server. Often, these application servers can also serve static files directly and thus take on most features of a webserver too.
However, as written above, most webservers are magnitudes faster and more scalable when serving static files. Also, some application servers such as Unicorn are not intended to be exposed to clients directly since Unicorn does not buffer requests and responses efficiently. Instead, they rely on a frontend server such as nginx for that.
Thus, as a conclusion: most Ruby application servers can be used without a webserver directly. With e.g. Puma this will work quite okay. To more efficiently serve static assets, or to loadbalance or protect your application, you can also introduce a webserver / proxy in front of your application server such as nginx or Apache.
I'm studing Docker and i just created a Rails app following the guide here https://docs.docker.com/compose/rails/ , the image used in this guide use the PUMA as server APP. When i up my container the app is already published on WWW by myipnumber:3000.
So here is my doubt, how is possible to my app is published on WWW without a Web Server like NGINX/Apache since these are aparenttly not installed in my host or container? (maybe they are but i cant see).
Puma is a rack-compliant application server that handles HTTP requests for you.
You'll need a web server for production deployment (but it's a different story).
Read also
Rack: https://rack.github.io/
Nice explaination by Justin Weiss: https://www.justinweiss.com/articles/a-web-server-vs-an-app-server/
Comparison or Ruby servers (a bit dated): https://www.digitalocean.com/community/tutorials/a-comparison-of-rack-web-servers-for-ruby-web-applications
I can program and develop in Ruby on Rails/JS/HTML/CSS to make a full stack app. However, there are holes in my understanding of the HTTP request/response cycle. Are the following points correct?
If I make a Rails app, and on the command line type rails server I get a local server, which I can make requests to. If I open a browser, type localhost:3000, and press enter, I am making an HTTP request to the local server.
Rails uses by default a web server called WEBrick, though there are others like Thin, Puma, and Unicorn. These are all pieces of software, and what makes them web servers is the fact that the software implements functionality to process HTTP requests.
When I run a local web server, it means that my computer is running one of these pieces of software that listen for HTTP requests.
Is the above what it means "to run a local web server"?
I have seen other examples of ways to "run a local web server". One of the is to run npm install -g http-server in a project directory, and then navigate to localhost:8080. Is this also just software that starts running and accepts HTTP requests on port 8080?
On a Ruby command line, install rack gem: gem install rack. Then in a new Ruby file we require 'rack', start a web server:
Rack::Server.start({ app: MySimpleApp, port: 3000 })
We can then define a web application MySimpleApp that is rack-compliant (object that responds to call method):
class MySimpleApp
def self.call
(...)
end
end
So now when we navigate in our browser to localhost:3000, MySimpleApp is executed. Is rack simply running it's default WEBrick server? Is what the above commands do simply run a local web server and define what to do when an HTTP request comes in (execute MySimpleApp)?
You're pretty much right on your understanding there. HTTP is just a text-based protocol that, like many, operates over TCP/IP.
The built-in WEBrick server isn't the best example of an HTTP server written in Ruby, but it's included for legacy reasons because it's often "good enough" to get you started. Pow is considerably better and despite being produced by the same company that produced Rails it's largely written in Node.
The beauty of HTTP, like a lot of internet based protocols, is it doesn't matter what language you use so long as you comply with the standard.
Rack is a layer that operates behind HTTP and provides a thin layer of abstraction on the request/response cycle.
A server is something that opens up a port (80, 443, 8080) for some sort of data transfer. Port 80 is the HTTP port and port 443 is the HTTPS port. 8080 is a commonly used port for development (as is 3000). https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
A local server by definition is a server running on your machine.
Overall, you are definitely on the right track.
Chicago Boss is a great Erlang Framework. It ships with many dependecies including mochiweb, yaws, and misultin. After installation, Chicago Boss runs a development server very well.I need to know which of the web servers it ships with, does it use by default ? and how can i change from one web server to another without compromising my Chicago Boss project ?
From CB Wiki:
All configuration takes place in boss.config in your project directory....
Webserver
port - The port to run the server on. Defaults to 8001.
server - The HTTP server to use. Valid values are:
mochiweb - The Mochiweb Web Server
misultin - The Misultin Web Server
So check in boss.config for which web server you use.
Hope this helps!
I wrote a real-time web app that consists of the following:
Rails to serve the web pages (listens on port 80)
Nodejs to handle real-time logic (listens to port 8888)
So on a particular page served by my rails app, the JS will use socket.io to establish a connection to my nodejs instance to allow real time http push.
Currently Nodejs communicates with Rails simply by updating the rails database. (I know this is ghetto but it works).
What are my options for deployment?
I have deployed simple web apps on heroku before and I really like the simplicity.
I have also deployed a web app with similar functionality (except it's made up of django + nodejs). I used HAProxy to do reverse proxying to handle direction of traffic to the correct process on my machine. However, I deployed this on a VPS server instead.
Note: the ugliness will probably revolve around:
I am relying on a common db
These processes are listening on different ports
We had this exact issue. We deployed them to separate Heroku applications, but kept them within the same code base. http://techtime.getharvest.com/blog/deploying-multiple-heroku-apps-from-a-single-repo outlines how to do it.
Manually set the buildpack
Set a config variable that you can reuse in step #3.
Create a custom web script that your Procfile uses
A custom script in bin/web
#!/bin/bash
if [ "$RAILS_DEPLOYMENT" == "true" ]; then
bundle exec rails server -p $PORT
else
node node/index.js
fi
And the Procfile:
web: bin/web
I would consider setting these two applications up as separate Heroku applications on different subdomains and just having them both on port 80. The communication between them goes through a shared database so they don't need to reside on the same machine or even datacenter. Socket.io supports cross domain requests on all browsers, so that shouldn't cause any problems.