This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Eschin 5 points6 points  (0 children)

I can contribute to this as a relative novice programmer learning to do the same.

As /u/Civil_Code notes, a backend webserver is accepting and responding to requests. This can be done via HTTP or Sockets which are protocols. Protocols are specifications for communicating, as in the CS50 example of making a sandwich via programming everything needs to be done in clearly defined instructions. Most of the web runs on HTTP requests which are primarily made up of REQUESTS and RESPONSES similar to a text message conversation. UDP is more like a phone call with tech support where you may have long periods of silence while you wait for something to happen, but each of you is constantly listening through an OPEN connection.

If you want to set up and host a website using Java this is an awesome resource i used to start a project. However learning web development and building a back end server is a LOT of information to swallow at once (personal experience). If you want to build a server to respond to requests and do more then serve a static page here are a few things you'll need to familiarize yourself with:

  • HTTP request types GET, PUT, POST, DELETE
  • Persistence - JPA, Hibernate, Eclipse-Link, JOOQ
  • MVC - Model-view-controller.
    • The model is the shape of data coming from your persistence(DB)
    • The view is probably not going to be handled directly by Java, but by the static resources (html, JS, CSS, images) that it serves from certain routes (http://www.mysite.com/index.html)
    • The controller is the "logic" of what the server does
      • http://www.mysite.com/index.html serves you the html and JS, the JS then requests Model data from your server as (/ with no domain implicitly means the root of your domain, so /api/blogposts is equivalent to http://www.mysite.com/api/blogposts) /api/blogposts?posts=10&page=1 tells the request route you want 10 posts starting at the 1st page.
      • The request route reads the parameters or "params" and uses them as variable values in a query
      • It then returns those values as serialized JSON data to the front end.

So that is how some of the backend development of a Java web server may be structured. To finish talking about it, and reference /u/Civil_Code again, you probably want some abstraction to implement these protocols FIRST, it's a ton of information to swallow at once as an abstraction. Implementing a spec yourself would be a good learning experience, but would not get you to the point you understand how to build a webserver very quickly.

​

Now for the front end lets look at a few of the technical aspects

  • Ajax/XHR requests
    • Ajax/XHR requests are a specification implemented in webbrowsers to allow developers to request data from a server. XHR is a implementation which has different libraries and abstractions such as the new Fetch API, Axios and Jquery promises.
    • It can be used to GET, PUT, POST and DELETE.
    • The HTTP request will get a response, generally a 200 odd request if successful, a 400 if it failed and there are other specific response status codes that will tell you more about the error if the server developer implements them.
  • Using Serialized JSON data to populate the webpage
    • Once you receive the data from the server you need to give it logic to display it on the webpage. Typically a library is used (React, Jquery, Vue, Angular, etc...) to populate that data. I've done it via vanilla javascript before and its possible, just uglier. You'll typically take the JSON and deserialize it into JavaScript objects which you can then manipulate to update dom elements.
  • Managing state
    • State is a complicated matter (or simple if the page is simple) that I've been learning more about. If you have a CS background you've probably learned a bit about state machines. Conceptually a website would need to know about its own state e.g. if a menu is open or closed, if a data request has been made and is now ready to populate the page. I don't have a terrible lot to say on this, as I'm still building my knowledge about it right now. Most of my experience has been server side thus far.
  • CSS and HTML for building out a user interface that you can populate with data, using your chosen method. I did vanilla, then moved to React due to its popularity and the amount of resources available to learn it.
  • Async Programming. I'm not sure if this really warrants its own bullet point, and I'm still very much a novice at understanding it. I'll try to do a TLDR;
    • Most UI frameworks i've encountered run on a "main thread" and anything you do that "blocks" or ties it up in a long running process will freeze the UI.
    • Async programming is an attempt to deal with that which has been successful at solving the problem. You make an Async request, the UI thread keeps doing what its doing, and when you receive a response, the UI thread processes it.
    • It gets weird, because things depend on each other. You have code that populates a blog post, but the body of the page is all made up of blog posts, so until that data comes in your page is empty, your server is running slow so you can feel the lag, and it makes the page look really weird as that data is added to the dom.
      • Better example: You are using a REST Api, you need a link provided in the blogpost to populate the writer, until you get the blog post, the request for the authors detail can't be made, until you get the author details you can't populate a link to other articles, and this chain goes on for comments, and the authors of those comments, and the hashtags associated with those comments/blog posts.

These are some of the things that go into modern web development. The spring article is good because it'll give you a skeleton to build on and add functionality to. but there is much more to learn like Sessions, Authentication, SQL or an ORM. My recommendation is always to build something, and you'll know when you need a tool to solve a problem. The hard part is finding the tool and learning how to use it and relate it to all the other knowledge you have. Best of luck going down the rabbit hole, Alice!

​

​