Make microservices truly “micro” and “hot”
Replacing SQL and stored procedure to develop business logic in Java in the microservices system can indeed gain framework advantages, but the development complexity is not “micro” at all. Java lacks the computational capability of structured datasets, and the code is much longer than SQL. Even with the help of technologies such as Stream and Kotlin, when faced with slightly more complex computational requirements, from the perspective of code length, its “micro” level is still far from comparable to SQL (stored procedures).
Even in terms of frameworks, microservices are not necessarily “micro” enough. Java is a compiled language, and when code changes, it needs to be recompiled and deployed, which is tedious and may force unrelated parts of the entire application to be compiled together and deployed. To make each service independent, it is necessary to use a heavy mechanism like Docker. Unable to achieve lightweight hot swap, which is very unfriendly for microservices that originally wanted to adapt to frequent business changes.
With the help of esProc SPL, microservices can truly become “micro”.
esProc SPL is an open-source software written in Java, which can be found here https://github.com/SPLWare/esProc.
Let’s take a look at how esProc SPL can solve the problem that microservices are not “micro” enough.
The root cause of tedious development problems lies in Java. esProc did not directly provide Java with more APIs, but instead designed a new programming language, SPL.
Java is a compiled static language that makes it difficult to implement dynamic data structures and convenient Lambda syntax, which is particularly common in structured data operations and the advantage of SQL.
Any SELECT statement in SQL will generate a new data structure, allowing for the addition and deletion of fields without the need to define the structure (class) beforehand, which is common in structured data operations. However, languages like Java won’t work effectively. It is necessary to define all the structures (classes) used when compiling the code, and it can be considered that new classes cannot be dynamically generated during the execution process (Java theoretically supports dynamic compilation, but the complexity is too high). If a specialized class is used to represent all data tables, and field names are also treated as data members of the class, it is not possible to directly use the class’s attribute syntax to reference fields, and the code is very cumbersome.
Lambda syntax is widely used in SQL, such as the condition in WHERE, which is essentially a Lambda expression. Although Java, a static language, currently supports Lambda syntax, it is far less convenient than SQL. A function header definition is needed to tell the compiler every time a Lambda function is about to be written, and the code looks messy. In Lambda functions, field names in the data table cannot be directly referenced. For example, when calculating amounts using unit price and quantity, if the parameter name used to represent the current member is x, it needs to be written in the verbose form of “x. unit price * x. quantity”. In SQL, it can be more intuitively written as “unit price * quantity”.
Only interpretive dynamic languages can implement these features of SQL, which can generate new data structures at any time, or determine whether the current parameter is a Lambda function based on the host function itself. Therefore, there is no need to write a definition header, and fields without table names can be correctly referenced based on the context.
SQL is an interpretive dynamic language, and so is SPL. Java, as well as Kotlin and Scala based on Java, are not, so it is difficult to write concise code in these languages.
On the basis of interpretive dynamic languages, SPL provides more comprehensive structured data objects (tables, records, cursors) and richer computational functions than SQL, including basic operations such as filtering, grouping, and join in SQL, as well as missing ordered and set operations in SQL. So, SPL code is usually more concise and easier to maintain than SQL, and of course much stronger than Java code.
Conventional sorting, written in SPL is more concise than SQL:
Orders.sort( -Client, Amount) Orders.groups( year(OrderDate), sellerid; sum(Amount), count(1) )
For more complex tasks, such as this one, calculating the longest consecutive days for a stock to rise, SQL needs to be written in multiple nested, lengthy, and difficult to understand:
select max(ContinuousDays) from (
select count(*) ContinuousDays from (
select sum(UpDownTag) over (order by TradeDate) NoRisingDays from (
select TradeDate,case when Price>lag(price) over ( order by TradeDate)then 0 else 1 end UpDownTag from Stock ))
group by NoRisingDays )
The same calculation logic is very simple using SPL:
Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())
SPL also has comprehensive process control statements, such as for loops and if branches, and supports subroutine calls. Only using SPL can achieve very complex business logic, directly forming a complete business unit, without the need for upper-level Java code to cooperate.
The data sources supported by SPL are also very rich, whether it is a relational database or NoSQL or Kafka or Restful, whether it is a regular two-dimensional table or a multi-level JSON, SPL can all calculate and process.
Very specifically, SPL code is written in a grid, which is very different from the code typically written as text. The independent development environment is simple and easy to use, providing single step execution, breakpoint setting, and WYSIWYG result preview, making debugging and development more convenient.
Here A programming language coding in a grid is a more detailed introduction to SPL.
This explains the ‘micro’ in the aspect of development complexity, and then let’s look at the framework aspect.
esProc SPL is pure Java software that can be seamlessly embedded into any Java application in the form of jar packages, thus enjoying the advantages of mature Java frameworks. esProc SPL provides a standard JDBC driver, allowing Java programs to call SPL code just like executing database SQL or stored procedures. This is equivalent to importing a lightweight and powerful database engine into Java.
SPL is interpreted and executed, and code modifications can be generated immediately without the need for further compilation and deployment. This naturally achieves hot swap of business logic, especially suitable for the diverse target scenarios of microservices.
SPL scripts can be stored as files and placed outside the main application, with each service corresponding to an SPL script, which naturally has independence. No longer requires the use of additional mechanisms such as VM or Docker, consumes minimal resources, and the framework becomes more “micro”.
With the support of esProc SPL, microservices can truly become “micro” services and are more suitable for “hot” applications.
