Design note: what EK9 leaves out
This note goes with the EK9 philosophy section of the Introduction to EK9. EK9 pulls many patterns into the language, but it deliberately leaves three areas out: user interfaces, a persistence layer, and how microservices are found and configured.
User interfaces
Many developers will want other front-end frameworks and will not adopt EK9 for front-end development. That is the main reason EK9 has Web Services built in: existing front ends can stay as they are and connect to an EK9 microservice using REST or in a RESTful way. You can also adopt micro front-ends and blend technologies within one web front end.
Front-end development is still in flux: native UI, mobile devices and the web pull it in different directions. UI development can, and probably will, stay outside the language; through HTTP and services the language can support UI tool kits.
SQL and persistence
You may wonder why (or be relieved that) EK9 does not abstract a data persistence layer. The main reason is that SQL tables are an inherent mismatch with Objects (and EK9 is not only 'OO' focused). With No SQL databases there are also persistence mechanisms with very different semantics and concepts.
Do not assume that an EK9 record is a record in a database table. It can be if that is what you intend, but a record can represent any aggregate of data, pulled together from a wide range of sources. With GraphQL, micro front-ends and microservices, data comes from different repositories, so assuming all data is held in one monolithic database is not wise.
Experience shows that an abstraction layer for SQL has immediate benefits. But in larger, long-lived software that includes OLTP and BATCH work, native SQL (or the NoSQL equivalent) is almost always needed in the end. You then write and rewrite the same functionality in both the abstracted form and SQL/NoSQL, which is not DRY.
It also means you cannot use pure SQL/NoSQL resources - written material or people - to improve, optimise and debug queries, and debugging or tuning almost always ends with looking at the SQL/NoSQL the layer generated.
So EK9 has no hibernate layer. As with HTML/CSS, EK9 accepts that most developers will (and will want to) use SQL/NoSQL in the dialect of their choice for the database of their choice.
Libraries, discovery and configuration
The hope is that a wide range of libraries will be developed for EK9, but many systems are now built as microservices, each written in the language that suits its functionality and its team. Building very large monolithic applications only to reuse existing libraries is behind us.
EK9 does not define discovery services, or a mechanism for a microservice to announce itself. That belongs to the configuration, management and deployment of software, and 'DevOps' staff will have their own preferred ways to deploy and manage microservices, since EK9 is designed to fit in with other languages and services.
For example, make a microservice command line or environment variable driven, so the port it serves can be configured. That gives 'DevOps' staff a familiar, obvious way to configure and start it. Consider configuration files only when there are many options.
Or consider a configuration data microservice that provides reference configurations for other microservices, breaking one microservice into two (or more). If every instance of a customer microservice uses the same configuration, all instances read it from there, and each instance needs very little configuration to start.
EK9 is not prescriptive about how application or microservice configuration is managed, and it does not introduce yet more concepts for software deployment and management.