ٰExciting Developments for Nawah 3


Next release of my free and open-source project which I've built tens of applications with is shaping up.

I don't speak of Nawah (Nawah on GitLab, Nawah on GitHub) although I use it daily to deliver great software and digital transformation solutions that fulfil robust and dynamic business requirements of my clients. One reason I don't speak of Nawah a lot is that the published version is not exactly the version I use, and the reason is, out team maintains our own version that incorporates some pre-defined components that allow us to rapidly develop and deliver new solutions. These components are semi-hard coded with Nawah version we use, and the development Nawah sees internally doesn't give us enough time to publish all these changes, however, by principle I always wanted Nawah to be FOSS-first, and version 3 is a good time to consider that.

A bit of history: Back in 2010, our team was still using mixture of tools to deliver solutions that were mainly powered by PHP. However, as the focus in our work shifted to digital transformation we realised we need to consider a move off PHP as the successful factor in the solutions we were delivering was the automation we implemented to business processes to our clients. Most of such automation tasks wouldn't be suitable to be run as PHP scripts tied to Cron jobs or be triggered with requests, as running PHP scripts as services wasn't considered a good practice those days. We used Bash, Ruby, and, Python to add such layer of automation. This allowed us to deliver solutions beyond digitalising business processes and onto digital transformation. We began to evaluate the situation, and decided to move all-in on Python. The move didn't happen over a night, as we already had some great assets, which we called CoreDro internally, that we could use for more projects, so, this was a slow move, but steady one. And, speaking of assets, we began to re-create the wheel, a better wheel, with Python. The new assets were called LIMP. In no time we found ourselves moving from assets to framework structure as our focus on digital transformation proved we had the vision for it. By 2014, LIMP became an established framework, I decided we will make it FOSS, however the actual work on that didn't see the light until 2016, when I began maintaining a public release of LIMP, and for next four years I continued to do so with variable traction. This made LIMP quite limited to anyone else, and I knew I had to take it all FOSS to make the contribution worth it.

As the lock-downs started to take place globally in 2020, more of our clients began to embrace cloud, where in comparison, majority preferred private disconnected servers at offices. This shift meant we can also move our focus on solving business problems than creating a full-fledged OS-like big ball of a solution. We wanted to mark this phase, and a rebranding was suggested for the framework where we went with Nawah. Nawah is an Arabic word (spelled نواة) that can be translated to "Physical centre of a thing", an example of correct use of the word is cell nucleus where "Nawah" is nucleus in this context, and similarly with atomic nucleus. I continued to maintain the project, now with a new name, however, it was still a version of what we were using and not exactly the same, which meant public development sometime was disconnected from our work. This proved to be a challenge as we didn't have enough resources to shift to FOSS-first approach, so we continued to do the work the same way.

Then, Nawah version 3 became a necessity; As it became clear there's no return back to private disconnected servers and businesses are all betting on cloud and being connected. We set the plan to migrate Nawah onto an event-driven development platform rather than an application framework. It is hard to explain in details how this came to be, and I'll spare this to another post where I'll discuss how we and our clients benefited when we began delivering development platforms to them rather than applications only. And, such a big change meant a new Nawah release.

Nawah version 3 will be FOSS-first, and we are gearing towards that as we develop it internally. And, once we make the public release, we will base all our work on it, rather than maintaining it as a fork.

So far, we are at technical preview stage of the framework area, with development platform technical preview coming soon. The technical preview is an internal phase where we will work with other teams to get the feedback we aspire to have to continue the development process of Nawah v3. In this phase, Nawah v3 can successfully generate a complete cloud-native, event-driven, service-structured application. For instance this is what two services of the technical preview application look like from code and cloud views:

  graph LR
    subgraph "Code View"
        subgraph "Service: order"
            subgraph order_api_rest_command["API: rest_command"]
                endpoint_put_orders("Endpoint: PUT /v1/orders")
                endpoint_post_orders_order_id("Endpoint: POST /v1/orders/{ORDER_ID}")
            end
            subgraph order_api_rest_query["API: rest_query"]
                endpoint_get_orders("Endpoint: GET /v1/orders")
                endpoint_get_orders_order_id("Endpoint: GET /v1/orders/{ORDER_ID}")
            end
            subgraph order_events["Events"]
                event_order_placed_v1("Event: order_placed_v1")
                event_order_updated_v1("Event: order_updated_v1")
            end
            subgraph order_views["Views"]
                view_orders("View: orders_v1")
                view_order_items("View: order_items_v1")
            end
        end
        subgraph "Service: warehouse"
            subgraph warehouse_api_rest_query["API: rest_query"]
                endpoint_get_warehouses("Endpoint: GET /v1/warehouses")
                endpoint_get_warehouses_warehouse_id("Endpoint: GET /v1/warehouse/{WAREHOUSE_ID}")
            end
            subgraph warehouse_hooks["Hooks"]
                hook_order_order_placed_v1("Hook: order_order_placed_v1")
            end
            subgraph warehouse_events["Events"]
                event_items_assigned_v1("Event: items_assigned_v1")
            end
            subgraph warehouse_views["Views"]
                view_warehouses("View: warehouses_v1")
                view_warehouse_items("View: warehouse_items_v1")
            end
        end
    end

    subgraph "Cloud View"
        subgraph "NS: nawah"
            mq("Message Queue")
            ingress("Ingress")
        end
        subgraph "NS: order"
            order_db("Database") --> order_pod_api_rest_query_v1
            order_pod_api_rest_command_v1 --> order_db("Database")
            order_pod_api_rest_command_v1("Pod: rest_command_v1") <--> order_svc_api_rest_command_v1
            order_svc_api_rest_command_v1("Svc: rest_command_v1") <--> ingress
            order_pod_api_rest_query_v1("Pod: rest_query_v1") <--> order_svc_api_rest_query_v1
            order_svc_api_rest_query_v1("Svc: rest_query_v1") <--> ingress
            order_pod_outbox_worker("Pod: Outbox Worker") <--> mq
            order_pod_inbox_worker("Pod: Inbox Worker") <--> mq
            order_pod_outbox_worker <--> order_db
            order_pod_inbox_worker <--> order_db
        end
        subgraph "NS: shipment"
            shipment_db("Database") --> shipment_pod_api_rest_query_v1
            shipment_pod_api_rest_query_v1("Pod: rest_query_v1") <--> shipment_svc_api_rest_query_v1
            shipment_svc_api_rest_query_v1("Svc: rest_query_v1") <--> ingress
            shipment_pod_outbox_worker("Pod: Outbox Worker") <--> mq
            shipment_pod_inbox_worker("Pod: Inbox Worker") <--> mq
            shipment_pod_outbox_worker <--> shipment_db
            shipment_pod_inbox_worker <--> shipment_db
        end
    end

What's exciting about the phase we at right now, is structure code (code required to generate application with structure described earlier) is less than 300 lines. So, multi-service, event-driven, cloud-native out-of-box ready-to-deploy application structure all in 300 lines. The structure code is statically typed per Python typing best practices, as well as validated upon launch. This has been a theme we followed since CoreDro days in 2006. We also focused on simplifying the language, and while we always find a new thing to learn with every project we work on and solution we deliver, we put our at-most effort to build Nawah v3 around a language that is development platform friendly, which we hope to reflect positively on developers the same way we had LIMP and Nawah be developers friendly since day one.

I'm very excited for what we are working on right now, and hope to share more with you soon.

Header photo: A diagram produced with Mermaid which describes cloud components to be created for a two-service application developed with Nawah

Creative Commons License

This page content - excluding exceptions - is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.