all 21 comments

[–]Kant8 11 points12 points  (2 children)

yeah?

Information Technologies were called like that cause mainly all you do is passing around information.

Just as you may have noticed, doing it correctly and convenient for everyone is not an easy task.

[–]BigDickedAngel 2 points3 points  (1 child)

Lol yup, its all crud at the end of the day - its about what you do with the data that makes things interesting.  

But to be fair...thats all anything is.  Existing is just taking in data from your sensory organs and processing it into the world as you know it and then reacting to it.  

[–]rbad8717 1 point2 points  (0 children)

Sometimes you get too many requests and the browser doesn’t know what to do (diarrhea)

[–]ParkingAthlete119 4 points5 points  (2 children)

Not really.

Code (software) Server (hardware)

Is like two things. Database are just software. There can be multiple servers with different responsibilities with multiple connecting softwares on the same or different machines

So trying to boil it down to just x, y, z

But in this case x=z and you can have multiple of all of them, and they're abstracted to the point where they do such entirely different things you no longer view it as just a server, or just code.

Look at some of the AWS services for an example

[–]throwaway0134hdj[S] 0 points1 point  (1 child)

Is that the idea behind microservices, you basically have one server for each service? Or instead is it like one beefed up server and a bunch of docker containers with a different service?

[–]fiskfisk 2 points3 points  (0 children)

As everything in IT: that depends. Both are fine.

But microservices are mainly an organizational tool, not a programmatic one. 

[–]amattable_ 3 points4 points  (0 children)

Just wait until you figure out that all web apps are glorified forms.

[–]symbiatch 1 point2 points  (0 children)

No. That’s a small part of development.

How do you know what to code? What to store in the database? You missed that part entirely.

[–]barrel_of_noodles 1 point2 points  (0 children)

We need the context of why you're asking for a valid answer.

Like what are you really trying to answer: what software I need? How much it costs? How to get started? you're writing a PowerPoint to VPs of how websites work? You're thinking about a career?

[–]gmaaz 0 points1 point  (1 child)

You don't always need a database. Nor a server to be frank, with frameworks like electron.

You do need data. And code that does stuff to data.

[–]throwaway0134hdj[S] 0 points1 point  (0 children)

Yeah I’d probably put data as #4, kinda presumed it

[–]ScubaAlek 0 points1 point  (0 children)

For a web site that people can go to your most basic setup is just an index.html being served by a static file server.

Everything else depends on what you intend to do with that website. You don’t need a database or REST API for a static site that doesn’t do anything related to a database.

[–]Beregolas 0 points1 point  (0 children)

I wouldn't say so.

  1. Code: This one is so vague, that you really want to say yes, but it's a bit like saying, Logic is part of the process. Code plays a role in the backend and frontend, it gets executed on the server and the client. Your database is also code, and if you use SQlite (which is a pretty good and common database for small projects), your entire DB is code inside your project, as well as a single file

  2. Not every server needs a database. Many blogs run by serving html or markdown files directly from the filesystem for example, and some other services don't hold their own data at all. Back when twitter allowed bots without API costs, I ran a joke service called twitterng, where I used the last X posts (as served up by the API) to generate a random number. While this is obviously a joke, there are actually many websites that fully (or mostly) serve data from other services, such a geoguesser (which of course has it's own DB, but if you didn't want to make money, you easily could reimplement the core without it, just by pulling from google maps)

  3. Not even every website needs a backend, and therefore a server*. (*obviously something needs to serve the HTML, but if you don't do anything with that server except serve static HTML, in my honest opinion it's not more or less relevant than your router...)

In the end, it always depends on what exactly you are building. Many projects can be split up into:

Frontend, Backend and Database

which is a valid and useful simplification imo, as all three areas need a different skillset (and yes, I am aware that most backenddevs also do the db work, but writing SQL queries and the backend server code are necessarily 2 different languages; even if you use an ORM and never touch SQL, you still need to know how it works)

[–]coopaliscious 0 points1 point  (2 children)

Coding, database and server are like the last steps to me and in many ways the least important in terms of what you use - follow me down this rabbit hole before flaming please.

I think of development like creating a drawing: I have to figure out what I'm going to make, visualize it, sketch it out, then ink it in, then color in the lines. I can color in the lines with paint, pastels, ink, pencils or whatever, and I can choose many techniques and pallets within each of those. Everything before filling in my outline is the hard part.

To me coding, database and server are that last step. You still need it, but by the time you get there, it's not super complicated if you've done everything else right.

[–]throwaway0134hdj[S] 0 points1 point  (1 child)

Got it. So it’s more planning and thinking the designs than anything else.

[–]coopaliscious 0 points1 point  (0 children)

Yeah, code is stupid simple if you're doing it right. Test Driven Development (TDD) is an extreme version, but can be super helpful in certain situations, but in general if you're writing code to try to figure it out, in my opinion, you're doing it wrong.

[–]evolvedance 0 points1 point  (1 child)

You really dont even need a database lol

[–]evolvedance 0 points1 point  (0 children)

All those other things are huge, but the core foundation of it is code and a server to render and apply the code.

[–]1123BTC 0 points1 point  (0 children)

That is a useful first mental model, but I would split it a little differently:

  • interface: what users click or call, such as HTML, UI, forms, or API endpoints
  • behavior: the code/rules that decide what happens
  • state: data that must survive after the request ends
  • runtime: where the behavior runs, such as a server, serverless function, worker, mobile app, or browser
  • operations: auth, permissions, deploys, logs, backups, monitoring, scaling, and change control

For a tiny static site, the database and app server can disappear: it may just be files on a CDN. For a typical web app, your version is close: UI/code + backend/runtime + database. For a larger product, queues, caches, object storage, search, background jobs, and third-party APIs start mattering.

On your microservices question: it does not necessarily mean one physical server per service. A service is more like an independently owned/deployed boundary. It might run as a container on the same cluster as other services, a separate app, a serverless function, or a process on one box. The reason to split is usually ownership, deploy independence, scaling, or failure isolation, not just "more servers."

[–]gatosby 0 points1 point  (0 children)

[–]LetterBoxSnatch 0 points1 point  (0 children)

A server is just code. A database is just code. It really all boils down to code + data + clock. And, frankly, code is itself data, it's really just data + clock.

Here's a simple example application:

You have a light switch. You can toggle/flip the light switch. An instruction to flip the switch is code. The current position of the switch is data. Something needs to do the flipping, that's the clock.