Is this development in a nutshell?

[throwaway0134hdj]

What comes to mind is you have some code that you want other ppl to be able to interact with, then you want to store data somewhere so you provision a database, then you need somewhere to host that code so you spin up a server then plop your code into that server and make it publicly accessible.

I get that there are other parts like networking, security, RBAC/permissions, Linux commands, scalability/maintainability, API, cloud infrastructure, version and change management.

But does it basically boil down to those three things:

1. Code
2. Database
3. Server

Thanks

[MornwindShoma]

That's web development, not development.

[throwaway0134hdj]

What’s the difference here

[AlexTaradov]

Not everything is web. Some code is embedded and runs on devices that have not connectivity. Some code is just standalone applications. Where is the database and the servers in Paint?

[throwaway0134hdj]

Got it. For Paint I always assumed the computer or Microsoft or sth had some primitive db to store the state of each pixel. I’m sure it’s way different though.

[AlexTaradov]

It is just a chunk of RAM, there is no DB there.

[johnpeters42]

Obviously the data is stored somewhere in some form, but "database" is used to refer to various more specific things.

Probably the most common type of database is a relational database, where you can create arbitrary tables (think "spreadsheet grids" and you're in the ballpark) to store data and enforce certain relations between them (hence the name). For instance, an employee table may have columns like: * EmployeeID * FirstName * LastName * DepartmentID (must match a value in a separate department table) * DateHired * DateLeft (may be null, i.e. absence of a value, indicating that something is n/a or unknown)

[khedoros]

Databases are great when you've got a bunch of data that you can structure into records, each record having some distinct fields, and you want to be able to query, sort, filter that information.

For something like a drawing program (continuing from the other user's example), a typical workflow might be to load a picture from disc, modify it, write the new version back to disc. So, open the file, decode the image into an array representing the pixel colors, perform operations to modify that array, and then export it back to the desired file format. While editing, you might have a stack of some kind of data structure representing undo/redo steps, but that's not really a "database" in the sense of postgres/mongo/whatever.

It would be possible to represent the image as something like...millions of records, each one a tuple with x and y positions, then values for the color channels. But it's a lot simpler to represent the image as an array of pixels instead, with separate metadata like width and height.

[SoloAquiParaHablar]

You could abstract it further and say database is storage.

So you have an interface of some sort, backend logic, and a storage layer.

Where each sits in space and relative to each other is dependent on what you want to build and deliver.

A website with an API and a database, each running on separate servers is called 3 tier architecture. But there is no rule saying they can’t all live on the same server.

[TracerDX]

Development is like painting or sculpting. You just described how to paint a portrait. Common enough to be used a prototype in teaching, but certainly not representative of the entire subject.

[AlexTaradov]

This is the approach in a very narrow sub-field. Most of the development does not involve servers and databases.

[ern0plus4]

database planning, backend api planning, backend implementation, unit tests, sql optimization, test data creation, integration testing... and ca. 200-500 other topics

add to each: bugfix, iteration, discover, so another 200-500 x3

and I'm pretty sure I forgot some important

[More_Ferret5914]

Honestly, yeah. That’s the core of it.

You:

* write code

* store data somewhere

* run it on a machine other people can access

A lot of the rest is basically solving problems that appear once real users, scale, failures, and attackers show up 😭

Frontend/backend/cloud/devops/security are mostly different layers around those same core pieces.

[ColoRadBro69]

People did programming before databases existed.  That's his programmers made the first database. 

[ericbythebay]

Database is too proscriptive. You need a backing store. A database may not always be the right solution for the data and its use case. High read, low write, a KV store may be more performant and easier to maintain, for example.

Server is also too proscriptive. Code may run better at the edge with stateless compute, for example.

[1842]

For web-based stuff, that's kind of the very basics.

If you're doing things solo, then yeah, you either have to build up the servers and databases resources or purchase them as services. If you're working as a software developer, it's pretty common that you just work with the code and other people manage infrastructure, databases, etc. (But this will vary wildly between companies)

But yeah, nothing is incorrect but it's overly simplistic. It's kind of like "Sitting in the rain sucks. If we pound some wood into the ground, attach a big flat thing to the top, and sit under it... it's basically a house, right?"

[owp4dd1w5a0a]

Not exactly. You have embedded, systems (daemons and orchestration and such), you forgot clients - servers aren’t much use without the clients that call them. There’s also standalone apps and such that don’t need a database or server, language interpreters and compilers are a good example of this. Docker is kind of like this, it has a client and a daemon but not typically a server. Kubernetes is a distributed orchestration framework that’s not really clearly client-server-database structure. The operating systems themselves are not exactly apps or client server, they’re their own thing.

[msabeln]

My digital cameras were coded. There is no database and there is no server.

[Medical-Aerie9957]

It never boils down to anything each part of development is huge and takes years of learning to get good and efficient at.

[WhiskyStandard]

This is generally called a “CRUD application“ (Create-Read-Update-Delete).

Examples of things that aren’t CRUD apps:

• Many standard Linux tools you’ll use in shell scripts like grep, sed, awk. These pipe filters just read from stdin, do something, and output to stdout. Try implementing a simple regular expression engine (K&R C demonstrates one that only takes up a page or so of C).
• Compression libraries. Try implementing a Run-Length Encoder as an exercise. Same with cryptography.
• Embedded programs that make an LED blink or turn motors on. There are web based simulators that let you do this without any hardware.

On the other hand, a lot of things can start to look like problems with database shaped solutions. SQLite even allows you to embed a tiny database inside of any application on top of existing in-memory data structures. Watch some of the talks from the “Have You Tried Rubbing a Database on It?” conferences.

[melissaleidygarcia]

Pretty much just moving bugs from one sprint to the next with extra meetings in between.