94

Yes. Generally two smaller less complex applications are much easier to maintain than a single large one. However, you get a new type of bug when the applications all work together to achieve a goal. In order to get them to work together they have to exchange messages and this orchestration can go wrong in various ways, even though every application might ...


85

Business logic doesn't go into the database If we're talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer. Databases do a few things really well: They store and retrieve data They establish and enforce ...


51

Does splitting a potentially monolithic application into several smaller ones help prevent bugs Things are seldom that simple in reality. Splitting up does definitely not help to prevent those bugs in the first place. It can sometimes help to find bugs faster. An application which consists of small, isolated components may allow more individual (kind of "...


49

Microservices are generally undesirable because they turn your software into a distributed system – and distributed systems make everything a lot more difficult. But a service-oriented architecture has some important benefits: different services can be developed and deployed independently by different teams different services can be scaled independently As ...


38

I'll have to disagree with the majority on this one. Splitting up an application into two separate ones does not in itself make the code any easier to maintain or reason about. Separating code into two executables just changes the physical structure of the code, but that's not what is important. What decides how complex an application is, is how tightly ...


29

Use a database with support for GIS (geographic information systems) queries. Most databases support this outright or have extensions, but the details will be database-specific (in their answer, Flater shows the syntax for SQL server). If you need to implement such queries within your application, you can implement a data structure that allows spatial ...


23

SOLID is a very good starting point. These are the 5 basic principles of object oriented design, which state what follows: Single responsibility principle: your objects (classes) should have single responsibility. In other words, there should be only one reason to change given entity/class. Open/Closed principle: classes should be open for extension, closed ...


23

In short, I would agree with your CTO. You've probably gained some performance at the expense of scalability (if those terms are confusing, I'll clarify below). My two biggest worries would be maintainability and lack of options to scale horizontally (assuming you are going to need that). Proximity to data: Let's take a step back. There are some good ...


17

The biggest disadvantage is that the client must have JavaScript enabled and be powerful enough to run a fair amount of it. It's also harder to satisfy accessibility concerns or anything else that relies on parsing static HTML (though something knowing your specific API can probably do better than HTML scraping). Finally, it's easier to have significant ...


16

I am a strong believer in keeping business logic out of the database as much as possible. However, as my company's performance developer, I appreciate that sometimes it's necessary to achieve good performance. But I think it is necessary far less often than people claim. I dispute your pros and cons. You claim that it centralizes your business logic. On ...


15

Easier to maintain once you've finished splitting them, yes. But splitting them is not always easy. Trying to split off a piece of a program into a reusable library reveals where the original developers failed to think about where the seams should be. If one part of the application is reaching deep into another part of the application, it can be difficult to ...


13

Object Oriented Design: Object-Oriented Design Is one of my favorite books on the topic, a bit dense, but otherwise great. Average of 4.5 Star Reviews. Object-Oriented Thought Process, The (3rd Edition): Object-Oriented Thought Process, The (3rd Edition). Is a more recently released option…also very good. Python 3 Object Oriented Programming: Python 3 Object ...


13

It's important to remember that correlation is not causation. Building a large monolith and then splitting it up into several small parts may or may not lead to a good design. (It can improve the design, but it isn't guaranteed to.) But a good design often leads to a system being built as several small parts rather than a large monolith. (A monolith can be ...


11

If your project is getting large, think of apps as reusable modules. You can separate out the functionality that is shared across your apps into its own app. See the discussions below for more thoughts on the matter: When to create a new app (with startapp) in Django? What is a Django “app” supposed to mean? What is an “app” in Django?


11

Yes, there's a better way. You need to use a spatial index. These indexes organize metadata about geometries to filter out far away geometries very rapidly, saving a lot of CPU cycles by avoiding the computations you describe. You shouldn't bother implementing one yourself as all major relational databases provide a spatial geometry type and indexes to go ...


10

I have worked in 2 different companies that had different vision on the subject. My personal suggestion would be to use Stored Procedures when execution time is important (performance). Since Stored Procedure are compiled, if you have a complex logic to query the data, it's better to keep that on the database itself. Also, it will only send the final data ...


10

Since SQL Server 2008, there is a geography data type which stores locations (lat/lon pairs) and makes it easy for you to write location-related queries. There is an existing StackOverflow answer that discusses this in-depth. A basic query to find the nearest 7 items: USE AdventureWorks2012 GO DECLARE @g geography = 'POINT(-121.626 47.8315)'; SELECT ...


9

There's a middle ground that you need to find. I've seen scary projects where the programmers use the database as nothing more than an overpriced key/value store. I've seen others where the programmers fail to use foreign keys & indices. On the other end of the spectrum, I've seen projects where most if not all of the business logic is implemented in ...


9

If your business logic involves set operations, most likely a good place for it is in the database because database systems are really good at performing set operations. http://en.wikipedia.org/wiki/Set_operations_(SQL) If the business logic involves some sort of calculation it probably belongs outside of the database/store procedure since databases are ...


9

Its okay to do a 'strict' or a 'nice' version of a delete endpoint, but you need to clearly tell the user what happened. We're doing a delete action with this endpoint. Likely DELETE /resource/bulk/ or something similar. I'm not picky. What matters here is that no matter if you decide to be strict or nice, you need to report back exactly what happened. ...


9

If an application needs to be optimized for performance, you don't rewrite the whole thing in a different programming language. Instead, you profile the application, find its "hot spots" (the code where the program is spending most of its clock cycles), and rewrite only the code in those hot spots. Generally, those hot spots will comprise 10 percent or ...


9

Think longer term - eventually... there will be a MegaCar 2.0 Or there will be another new car company with only the one model. Or one model companies all go out of business. Keep it the way you have it as if there were multiple models for each manufacturer, and deal with it when you get the results of your select statement. Check number of rows returned, ...


8

In practice, the cases where allowing remote access to a database are extremely rare. By allowing a direct access to a database, you let, by default, anyone: Access all the data in your database (so, in your case, all the employee data), Change it, because it's funny, Delete everything, because it's even funnier. You can give remote access: If you are 99,...


8

Depends on how database-savvy your developers are, but normally yes. DBAs are usually better at spotting potential performance issues, plus it gives them a heads-up in case they need to do anything special or unusual when creating the database (allocating space on multiple drives, setting up failover plans, allocating unusually large buffers or temp ...


8

I don't think they are suggesting it for speed. Sending emails becomes a problem when you need to send a lot of them from a single IP. That IP might end up as a spammer and so your emails will not be sent anymore. Also if you try to send an email and it bounces for some reason, you the sender, must resend it, and check again if it fails and if so, send it ...


7

The answer to use an ORM that allows you to abstract that away from the databases themselves. NHibernate is the first that comes to mind, though EF is an acceptable choice is there's an adaptor for the DBs you need. I'm not sure how good the support is for DB2, but SQL Server and Oracle work fine. As to stored procedures and trigger: don't use them. As ...


7

Disadvantages I often see with Single Page Web Applications: Inability to link to a specific part of the site, there's often only 1 entry point. Disfunctional back and forward buttons. The use of tabs is limited or non-existant. (especially mobile:) Take very long to load. Don't function at all. Can't reload a page, a sudden loss of network takes you back ...


7

There is nothing wrong with what you are doing if your purpose is to learn. Many developers leave a string of half-written applications behind them when they had finished everything interesting in them. However, if you want to write something and finish it, pick a problem you want solved then do the minimum you need to solve it. Use existing libraries and ...


7

Because terminal emulators are provided to accommodate a simple style of human-computer communication, the command line, which remains extremely useful in some contexts. Back when the command line and hardware terminals was all we had, it was clear that they were awfully limited for some contexts. Folks began to push their capabilities, giving us ANSI, ...


Only top voted, non community-wiki answers of a minimum length are eligible