Ideas behind the project

Ask yourself the following question: "Is it a good idea for a web framework to support many databases?".

At Wivvies, the answer is: NO, as this means you are limited to database access based on lowest common denominator.

We think it is a shame that powerful databases such as Oracle, Microsoft SQL, PostgreSQL and MySQL, and then their functions and speed are not utilized by the ORM facilities in various frameworks that also have to support SQLite, Microsoft Access and other simpler database systems.

Therefore, Wivvies decided to create a python framework, where the main idea was to utilize PostgreSQL to the full potential of this excellent database. Full support for variable types, stored procedures and triggers in the database, direct JSON formatting in SQL queries, security setup with user groups at database level, and a number of other PostgreSQL specific "super functions".

Our backend is an "API monster", with speeds that beat traditional frameworks/ORMs like django and flask/SQLAlchemy with multiple lengths - not a 30-40% but in many cases 100-1000% improvements. Our secret weapon is logic moved down into stored procedures at the database level instead of logic in web framework, combined with complex queries that format the answers to the front-end in JSON at the database level, instead of having to go through a serializer at the framework level.

We built this framework on top of FastAPI, which is also python based, but where a large parts of the underlying libraries are written in C and thus heavily optimized.

We understand that logic in multiple layers becomes more complex for programmers, so we generate most of the code for you directly via a code generator.

Manifests and code generation

At Wivvies, we are lazy - we want to define as few things as possible in a requirements specification, and we want changes can be done from one place - no need to enter 10 places in the code, because you have changed something on an input form.

Therefore, AG Manifest uses manifests, where tables, columns, formulas, relationships between tables, queries, security groups, validations, etc. are described in one place, and this place determines the functionality for web applications, mobile applications, Windows/Mac/Linux applications and for that matter also form the basis for automatic documentation.

Too good to be true? Absolutely not, we use very detailed manifests (information) that store all information about the database and the operation of the application. We use these manifests to code generation: SQL scripts, Python code and Flutter front-end, all level are of course connected.

When you use a label or a text field in AG Manifest generated applications, the individual elements receive information from manifest about how they should behave, e.g. in relation to formatting, placement on screen, translation between languages, validation etc.

In fact, a "side benefit" is that these manifests are in the database, and therefore mobile applications do not have to be re-issued so many times (a cumbersome and slow process) - in the vast majority of cases changes can be made by simply changing in manifests on the server. Translations for many languages are also on the server instead of a file that is "baked" into the mobile application, so new language versions do not mean new releases of mobile apps.

There is just something satisfying about defining just a few lines of instruction in some simple text files, and seeing thousands of usable lines of code are automatically generated - it's a delight for the "lazy eye".

Speed

Did you know that when you call a query in Django that uses several tables, you risk generating several hundred SQL statements that are sent against the database every time this query is encountered in the execution of the program?

The first time you install a debugger to a django project (and for that matter most other ORM systems), then you will be shocked! You typically do not experience problems while developing and the amount of data is limited, but when the system is in production, the user base increases and the data amount explodes, then serious performance problems can occur, if the programmer is not careful.

In AG Manifest we define all queries via a JSON syntax (you don't need to be sharp in SQL), which ensures data retrieval in one (and only one) SQL call. Also, we format the result to JSON before the result set leaves PostgreSQL, thus the web server only has to forward the information to the front-end - this approach creates huge speed improvements.

At the same time, one of the philosophies of AG Manifest is that tables cannot be "touched" by programmers. All inserts, updates or deletes of data take place via stored procedures, and all queries via pre-defined views. This philosophy ensures that all standard operations against the database are compiled into the database cache (a powerful PostgreSQL facility), so the database needs far less resources to execute a command.

Documentation and test

If you are a programmer, how do you feel about documentation? We in the IT industry all know the answer: Documentation is important and we should do it, but we are so busy that we rarely get to it. The answer is the same when it comes to testing code.

AG Manifest demand specifications are detailed and structured in the form of manifests, and we can automatically create word documents that reports every single detail inside the system in a readable and understandable form.

At the same time, AG Manifest automatically creates unit tests for each individual table, which allows you to test create, update, delete and query data automatically - unless things get very complicated, don't write test cases yourself... AG Manifest does it for you!

It is usually always problematic to define reports and statistics while developing a software system. For the most important part of these parts is missing: Data. AG Manifest offers a module that creates realistic test data very easily, even thousands or millions of records - a relatively simple, but often overlooked part of application development.

Wivvies recommends running these applications via NGINX and Gunicorn, which is why we also generate the configuration files for these production systems, ensuring a simpler installation experience. We can also create automatic docker scripts for you.