Stacks on Stacks
The Rails framework as insight to “full-stack development”
As a beginner developer, a lot of terms, both technical and non-technical, have been tossed at me; one of the first and most oft-mentioned of these was the idea of “full-stack development”. Since I began my journey on the road to the far off Neverland of “Web Development,” I have casually and confidently tossed out that phrase to experts and non-experts alike, wearing it like a badge of my budding expertise and technical prowess. But until only recently, I harbored a dirty secret: I had no idea what “full-stack development” actually meant.
That’s not to say that I had no inkling of the meaning of the term. I was generally aware of a “front-end,” code meant to create user interfaces, and a “back-end,” code meant to perform calculations and manage data, and that being a “full-stack” developer entailed working with both of these ends. But that was about it. If someone were to ask me what “full-stack development” meant, I imagine that this answer would be terribly disappointing and wanting of elaboration. Imagine asking a doctor about human physiology, only to be told that it consisted, generally speaking, of a “front-end” and a “back-end,” and that “doctoring” entailed working with both of these ends. I imagine that you would want a new doctor.
The lack of a clear definition of “full-stack development” was soon accompanied by another concern, the latter of which I had originally believed to be unrelated to the former. This second concern emerged as a result of my coursework at the Flatiron School related to Ruby on Rails, a concern that roughly took on the phrasing of “What the hell is Rails?” Rails seemed a strange tale of Ruby, HTML, SQL, and who knows what else, told in the familiar language of Ruby, but in a strange, foreign sounding dialect.
As a slightly more learned developer than the me-of-three-weeks-ago, I took on the challenge of researching the component parts of Rails and understanding a little bit more about its architecture. In my research, I came across a marvelous explanation of Rails and the philosophy behind its design. It managed to not only shed some light on the overall structure of Rails, but also began to give me a better understanding of the individual “stacks” that constitute “full-stack development.”
Rails as a window to full-stack development
There’s a lot to Rails, and I don’t plan on going into great detail about its functionality. What I will concern myself with at this juncture are the technologies utilized in Rails that work together to make it a full-stack framework.
The most basic Rails framework relies on several technologies that constitute its stack:
- An operating system (e.g. Mac OS, Linux, Windows)
- WEBrick Web Server
- Ruby on Rails
The presence of operating systems on the stack almost goes without saying, but it is important to recognize their place on the stack as they are the cores of our machines’ systems. Different operating systems have different architectures, different interactions with applications, and different advantages to their use. Some of these advantages (and disadvantages) are the result of the architecture itself, while others, such as application compatibility, are the result of the markets each serves.
SQLite serves as the database manager, inserting, querying and persisting data. It is possible to persist data by other means, but in my understanding, SQL is lightweight, executing queries with little use of system resources. For very small programs with little data, the difference is small, but for web applications like Twitter or Facebook that execute thousands and thousands of queries on databases containing millions of data points, the difference is, to say the least, important.
WEBrick Web Server is Rails’ portal to the web, allowing the Rails applications hosted on our machines to be accessed from the internet through ports. As a novice, I cannot comment on the functionality of WEBrick, let alone its performance relative to other web server technologies like Apache, but it has the advantage of being preloaded with Ruby, a boon to beginners like me who want to learn web development without first getting too tangled in DNS’s, TCP/IP’s and a million other acronyms.
Ruby on Rails is the glue that connects all of these technologies. Rails itself is a library that is built for Ruby, and while it is so specialized that it may appear to novice Rubysists to be an entirely distinct language, it is in fact still Ruby code. Rails acts like a middle man, establishing a connection through the web server, executing SQL queries, and displaying the data through HTML based web pages. This is where our objects live and where much of the computing logic occurs: while SQL handles data storage and HTML handles display, Rails processes requests from a user, executes queries, and operates on data. Rails was designed to cut out the tediousness of building directories and establishing connections between our various technologies so that developers can focus more on actually building applications rather than futzing around with environments and relations between files and repositories.
So how is this related to full-stack development in general?
The basic Rails stack outlined above is just one of many different stacks, each using different technologies with their own particular advantages. Facebook, for instance, was built on a LAMP (Linux, Apache, MySQL, PHP) stack, while other websites might substitute PHP with Rails, or My SQL with PostgreSQL, or Apache with Nginx. Regardless of the specific technologies used, the overall structure of a full-stack is, in general, as follows:
- Web server
- Application language
Each technology has a specific objective on the stack: the OS acts as the core of our machine, the database persists information, the web server connects local files to the web, the viewer displays the information, and the application language binds these entities and facilitates their communication. As a novice, it’s comforting to know that despite the plethora of technologies and frameworks available to a developer, there is an overall pattern of development that is generally applied. To me, this is a very neat approach to what could potentially be a giant, confusing mess.
There is still much that I do not know about the individual constituents of a full-stack. Yet knowing that these are the key elements of a stack helps clarify what had been for me mysterious action at a distance. I imagine that some beginner developers who find themselves in similar positions are comfortable with diving headfirst into the thicket and learning the lay of the land as they go. But for others like me, even a cursory glance can be really insightful and helpful in understanding at least a little a bit about what’s going on down below.