Coder Legion - Recent posts tagged application

Why Enterprises Need a Digital Backbone for Scalable Growth

Thu, 08 Oct 2026 05:23:44 +0000

Enterprise technology has changed dramatically over the past decade. Businesses that once relied on a handful of applications now operate across cloud platforms, SaaS tools, customer systems, data platforms, communication channels and specialised business applications. Each solution may solve a specific problem, but the growing number of disconnected systems can create a problem of its own: complexity.

As organisations scale, technology cannot simply be about adding more applications. Enterprises need an architecture that allows different systems, teams and processes to work together without creating unnecessary friction. This is where the concept of an enterprise digital backbone becomes increasingly important.

An enterprise digital backbone provides the technological foundation that connects core business operations. It helps organisations bring together applications, data, workflows and services so that technology becomes an enabler of growth rather than a collection of isolated systems.

Why Traditional Enterprise Technology Struggles to Scale

Growth often happens faster than technology teams can redesign their infrastructure. A company may start with a CRM, introduce an ERP system, add a customer support platform and later adopt separate tools for analytics, communication, HR, finance and operations. Over time, these systems accumulate.

The problem is not necessarily the individual applications. Most of them may be excellent at what they were designed to do. The challenge arises when they need to exchange information and support the same business processes.

Employees may have to move between multiple applications to complete a single task. Data can become duplicated across systems. Reporting may require information to be collected manually from different sources. Technology teams may also spend significant time maintaining integrations instead of developing capabilities that directly contribute to business growth.

This creates what can be described as a technology fragmentation problem. The more fragmented an enterprise becomes, the harder it is to maintain consistency, visibility and agility.

Building an Architecture Designed for Enterprise Complexity

A scalable technology environment begins with the right architectural foundation. An enterprise-grade platform architecture is designed to support large-scale operations while remaining flexible enough to accommodate changing business requirements.

Unlike an approach where every new requirement results in another standalone application, a platform-oriented architecture focuses on reusable capabilities and connected services. This allows organisations to build new workflows and applications on top of a common technological foundation.

Scalability is an important part of this equation. Enterprise systems need to handle growing numbers of users, transactions, data sources and integrations without constantly requiring structural changes. At the same time, scalability should not come at the cost of manageability.

A well-designed architecture should also consider security, reliability, interoperability and governance from the beginning. These considerations become significantly harder to introduce when technology environments have already grown into a complex network of disconnected systems.

The Shift Towards Platform-Based Enterprise Technology

The rise of SaaS has changed how businesses acquire and use technology. Instead of implementing every capability from scratch, organisations can now access specialised software through subscription-based models.

However, SaaS adoption can create a new form of complexity. An enterprise may use dozens or even hundreds of SaaS applications across departments. While each application can improve productivity, managing an increasingly large SaaS ecosystem can become difficult.

This is driving interest in the enterprise SaaS enablement platform model. Instead of viewing SaaS applications as isolated destinations, enterprises can create an environment where different services can participate in connected business workflows.

The objective is not necessarily to replace existing applications. It is to make them work more effectively together.

For example, information captured through one business application could trigger a workflow in another system. Data generated through operational processes could be made available to analytics platforms without repeated manual intervention. Internal teams could access the information they need through connected workflows rather than switching between multiple systems.

This approach allows businesses to preserve the value of specialised SaaS applications while creating a more unified technology environment.

Data Is at the Centre of the Digital Backbone

A digital backbone is only as effective as the data flowing through it. Enterprises generate enormous amounts of information through transactions, customer interactions, operational processes and internal activities.

When this information remains trapped in separate systems, organisations struggle to develop a consistent view of their operations.

Connected architecture can help create a more reliable flow of information across business functions. Instead of repeatedly copying data between systems, organisations can establish structured connections that allow relevant information to move where it is needed.

This has implications far beyond reporting. Better-connected data can support faster decision-making, more personalised customer experiences and more efficient internal operations.

It can also create the foundation for artificial intelligence. AI systems require access to relevant, reliable and contextual data. If enterprise information remains fragmented across disconnected applications, extracting that context becomes considerably more difficult.

A strong digital backbone therefore becomes an important prerequisite for organisations looking to make broader use of automation and AI.

Integration Should Enable Business, Not Slow It Down

Integration has traditionally been treated as a technical requirement. Increasingly, it should be viewed as a business capability.

When integration is designed properly, employees may not even notice it. Information simply appears where it is needed, workflows progress automatically and different systems work together in the background.

Poorly designed integration has the opposite effect. It can introduce delays, create duplicate records and increase dependency on manual processes.

Modern enterprises therefore need to think beyond connecting two applications. The larger objective is to create an ecosystem where applications, data and workflows can interact consistently.

This requires organisations to consider APIs, interoperability, identity management, security, data governance and workflow orchestration as parts of a broader architectural strategy.

Preparing the Enterprise for Continuous Change

Perhaps the biggest advantage of a strong digital backbone is adaptability.

Business requirements rarely remain static. New markets emerge, customer expectations change, regulations evolve and new technologies appear. An architecture that is tightly coupled to a fixed set of applications can make these changes expensive and time-consuming.

A platform-oriented environment provides greater flexibility. New applications can be introduced without completely redesigning the technology landscape. Existing systems can evolve while continuing to participate in broader workflows.

This does not mean that every enterprise needs to abandon its existing technology investments. In many cases, the smarter approach is to create an architectural layer that connects and extends what the organisation already has.

The goal is simple: make technology easier to change without making the business harder to operate.

Where ItNet Fits into the Enterprise Technology Landscape

ItNet by Imbibe Technologies is designed around the idea of creating a connected technology foundation for modern enterprises. Rather than positioning itself as another isolated business application, ItNet focuses on providing a cloud-native enterprise platform that can support applications, services, integrations and business workflows within a broader digital ecosystem.

For organisations dealing with fragmented systems and growing technology complexity, a platform approach can provide a way to connect existing capabilities while creating a foundation for future digital initiatives. ItNet is particularly relevant for businesses looking to move towards a more integrated and scalable technology environment without treating every new requirement as a separate technology project.

The broader value of such a platform lies in its ability to provide an architectural foundation on which organisations can build, integrate and evolve their digital operations.

Building the Next Generation of Enterprise Technology

Digital transformation is no longer simply about moving processes online or adopting the latest software. The bigger challenge is creating an environment in which technology can continuously evolve with the business.

An enterprise digital backbone provides that foundation by connecting applications, data and workflows into a more coherent ecosystem. An enterprise-grade platform architecture can help organisations scale without allowing complexity to grow unchecked. Meanwhile, an enterprise SaaS enablement platform can help businesses get more value from the growing collection of cloud applications they already use.

The enterprises that succeed in the next phase of digital transformation will not necessarily be those with the largest number of applications. They will be the ones that can make their technology work together intelligently.

That requires moving from a collection of disconnected tools towards a connected digital foundation.

ItNet can help enterprises take that step. Explore ItNet by Imbibe Technologies and build a more connected, scalable and future-ready foundation for your organisation.

Building Better Enterprise Dashboards with Ext JS Themes and Templates

Thu, 01 Oct 2026 10:13:25 +0000

Modern enterprise applications are expected to do much more than simply display data. They need to make complex information easy to understand, provide smooth interactions, work across devices and support users who may spend several hours a day inside the application. This is particularly true for administrative portals, analytics platforms, CRM systems, operational dashboards and business management applications.

For developers building these applications with Ext JS, choosing the right theme or template can make a significant difference. A well-designed interface provides more than visual appeal. It creates consistency across screens, improves usability and gives development teams a stronger foundation on which to build sophisticated applications.

This is where Ext JS themes and templates become valuable. Instead of designing every component from scratch, developers can start with an established interface structure and adapt it to the application's requirements.

Why Ext JS Remains Relevant for Enterprise Interfaces

Enterprise software often has very different requirements from consumer-facing websites. A business application may need data grids, charts, forms, navigation panels, user management screens, reports and multiple levels of administrative controls, all within the same application.

Ext JS is designed around this type of application development. Its component-based approach allows developers to create interfaces with reusable elements while maintaining a consistent structure throughout the application.

However, functionality alone does not automatically create a good user experience. An application with dozens of powerful components can still feel difficult to use if its navigation is confusing, its visual hierarchy is inconsistent or important information is buried beneath unnecessary interface elements.

A thoughtfully designed Ext JS theme or template addresses these concerns from the beginning.

The Role of an Ext JS Admin Template

Administrative applications frequently contain large amounts of information. Users may need to move between dashboards, tables, forms, reports and configuration screens several times during a single session. Navigation therefore becomes an important part of the overall application experience.

An Ext JS classic toolkit admin template can provide developers with a ready-made structural foundation for this type of application. Instead of starting with an empty project and deciding how every screen should be organised, developers can work from an established layout containing familiar administrative patterns.

This can include elements such as side navigation, headers, dashboard panels, data tables and content areas. The advantage is not simply saving development time. A coherent structure also makes the application easier for users to understand.

For businesses, this consistency can be especially useful when applications grow over time. New modules can follow the same design language rather than introducing completely different interface patterns.

Choosing the Right Ext JS 7.x Dashboard Theme

Dashboards have become central to modern business applications. Managers want to see key metrics quickly, while operational teams may need detailed information and real-time updates. A dashboard therefore needs to balance information density with clarity.

An Ext JS 7.x dashboard theme can provide the visual foundation for presenting this information effectively. Cards, charts, tables, summary panels and navigation elements can be arranged into a layout that makes important information easier to locate.

The right dashboard design should not attempt to display everything at once. Instead, it should establish a clear visual hierarchy. Critical information should be immediately visible, while secondary information can remain accessible without competing for attention.

This becomes increasingly important as enterprise applications become more data-intensive. A dashboard should help users interpret information rather than simply give them more of it.

Ext JS 7 Classic Toolkit Themes for Established Applications

Many organisations have applications that have been developed and maintained over several years. Rebuilding an established system simply to introduce a new interface may not always be practical.

For such environments, an Ext JS 7 classic toolkit theme can provide a way to modernise the visual experience while maintaining the underlying application architecture.

The Classic Toolkit is particularly relevant for applications that rely on desktop-oriented layouts and complex enterprise components. Developers can use a theme as a starting point and customise typography, spacing, navigation, panels and other interface elements according to the application's requirements.

This approach can help businesses improve the presentation of an existing application without necessarily abandoning the components and workflows that their users already understand.

Modern Interfaces with the Ext JS 7 Modern Toolkit

Enterprise users increasingly access applications from different screen sizes and devices. While desktop environments remain important for many business applications, responsive and touch-friendly experiences are becoming more relevant.

An Ext JS 7 modern toolkit template can provide developers with a foundation for building interfaces suited to modern application requirements. The Modern Toolkit is designed around experiences that can adapt more naturally to different device contexts.

The choice between Classic and Modern should ultimately depend on the application's requirements rather than simply following a trend. The nature of the existing application, target devices, component requirements and user workflows all play a role in determining which approach makes sense.

A good template gives developers flexibility while allowing the interface to remain consistent with the application's purpose.

Why Starting with a Template Can Improve Development

One of the biggest advantages of a well-structured template is that it reduces repetitive design decisions. Developers do not have to repeatedly determine how navigation should work, how content should be positioned or how common interface elements should look.

That foundation can allow teams to focus more attention on the functionality that makes their application unique.

Templates can also contribute to consistency across large development teams. When multiple developers work on the same enterprise application, a shared interface structure can reduce variations between different modules.

This becomes particularly valuable as applications expand. What begins as a relatively small administrative portal can eventually contain dozens of modules. Without a consistent design foundation, the user experience can gradually become fragmented.

A strong theme helps prevent that fragmentation.

Performance and Usability Still Matter

A visually impressive dashboard is not enough. Enterprise applications need to remain practical when handling large datasets and complex workflows.

Developers should therefore consider factors such as component behaviour, data loading, navigation efficiency and the amount of information presented on each screen. A theme should support these requirements rather than simply decorate the application.

Usability also needs to be considered from the user's perspective. If employees have to spend time learning where common functions are located or navigating through unnecessarily complicated screens, the productivity gains expected from the application can quickly disappear.

The best interface is often the one that users understand without having to think about the interface itself.

Customisation Makes the Difference

Pre-designed themes provide a foundation, but most serious enterprise applications require customisation. Every organisation has different workflows, branding requirements and information structures.

A useful Ext JS theme should therefore be treated as a starting point rather than a finished product that must remain unchanged.

Developers can adapt layouts, components and visual elements to reflect the application's requirements while maintaining a consistent underlying design language. This allows businesses to achieve a balance between development efficiency and a distinctive application experience.

The goal is not simply to make an application look different. It is to make the interface work better for the people using it.

What Is ExtNukes?

ExtNukes is a platform focused on Ext JS themes and templates designed to help developers create professional, modern and functional interfaces for their applications. Its collection of Ext JS resources provides developers with ready-made design foundations that can be adapted to different project requirements.

For teams working on dashboards, administrative applications and enterprise software, ExtNukes can reduce the effort involved in creating an interface from the ground up. Instead of spending extensive development time establishing common UI structures, developers can start with a more complete foundation and focus on custom functionality and business requirements.

The value lies in combining a structured starting point with the flexibility developers need to create applications that are genuinely tailored to their users.

Build Your Next Ext JS Application on a Stronger Foundation

Enterprise application development does not have to begin with a blank screen. The right ExtJS theme or template can provide the structure needed to create an interface that is consistent, practical and easier to scale.

Whether you are developing an administrative portal, creating a data-rich dashboard or modernising an existing enterprise application, choosing an appropriate toolkit and design foundation can influence both development efficiency and the final user experience.

Explore the Ext JS themes and templates available through ExtNukes and find a foundation that fits your next project. Visit ExtNukes today, explore the available templates, and take the first step toward building a cleaner, more capable and more professional Ext JS application.

Stop Slow Laravel: Your Next Architectural Leap Is Here!

Wed, 01 Jul 2026 06:34:24 +0000

Stop Slow Laravel: Your Next Architectural Leap Is Here!

Introduction

It’s 2026, and the landscape of web development has evolved dramatically. If your Laravel applications are still relying on traditional PHP-FPM for request handling, you might be leaving significant performance on the table. The conversation around application speed has moved beyond mere query optimization; it’s an architectural paradigm shift. Enter Laravel Octane, a powerful package that integrates your Laravel application with high-performance application servers like RoadRunner or Swoole. This isn’t just about making PHP “faster”; it’s about fundamentally transforming how your application processes requests, ushering in an era of unprecedented throughput, reduced latency, and blazing-fast API responses. Octane transitions your application from a stateless, “boot-on-every-request” model to a persistent, long-running process, eliminating the costly framework bootstrap for each incoming call.

Code Layout and Architectural Walkthrough

Embracing Laravel Octane demands a shift in mindset, particularly regarding application state. Let’s walk through the essential steps and considerations to integrate Octane into your project.

1. Installation and Setup: Getting started with Octane is straightforward. You first install the package via Composer:

composer require laravel/octane

Next, you’ll install Octane into your application, choosing your preferred server driver (RoadRunner or Swoole). RoadRunner is often simpler to get started with due to fewer external dependencies for many environments.

php artisan octane:install

This command publishes the config/octane.php configuration file, which allows you to fine-tune settings like the number of worker processes, maximum requests per worker before restarting, and more.

2. The Persistent Server Model: Unlike FPM, which reboots your entire application for every request, Octane leverages a persistent application server. When you run php artisan octane:start, a dedicated server process (RoadRunner or Swoole) is launched. This server loads your Laravel application once, keeping it in memory. Subsequent requests are then routed to this already-booted application instance. This fundamentally eliminates the overhead of bootstrapping the framework on every single request, leading to dramatic performance improvements.

3. Embracing the Stateful Mindset: This is the most critical aspect of adopting Octane. Because your application remains loaded in memory between requests, global state can persist, leading to unexpected behavior if not managed carefully. Key areas to monitor:

Static Properties & Global Variables: Any data stored in static properties or global variables will persist across requests. This can lead to data leaks or incorrect behavior if not reset.
Service Container Bindings: While Octane intelligently resets many core framework services, custom singleton bindings in your service container might retain state.
Opened Resources: Database connections, file handles, or network sockets that are not properly closed might accumulate or become stale.

Octane’s Mitigation Strategies: Octane provides powerful hooks to manage state:

Octane::onRequest: You can register callbacks to be executed at the beginning of each request. This is ideal for manually resetting any custom global state or re-binding services if necessary.

use Laravel\Octane\Facades\Octane;

Octane::onRequest(function ($request, $app) {
    // Clear any custom static caches
    MyCustomService::$cache = [];
    // Rebind specific service if it holds request-specific state
    $app->bind(SomeService::class, fn () => new SomeService());
});

Octane::onWorkerStopping: This hook can be used for cleanup tasks when a worker process is gracefully shutting down.
Automatic Resetting: Octane intelligently resets many core Laravel components, such as request input, session data, authentication state, and even clears resolved instances from the service container (unless explicitly configured otherwise).

For most well-architected Laravel applications that rely heavily on dependency injection and avoid excessive global state, the transition is smoother than anticipated. Focus on ensuring your services and controllers are stateless or properly reset if they must hold state.

Conclusion

Adopting Laravel Octane is no longer an edge-case optimization for the ultra-high-traffic elite; it’s becoming the baseline for modern, efficient Laravel applications. The architectural shift to a persistent application server, powered by RoadRunner or Swoole, fundamentally redefines performance. By eliminating per-request framework bootstrapping, Octane delivers 10x throughput, significantly reduced latency, and an incredibly responsive user experience. While it demands a careful consideration of application state, the performance gains and competitive advantage it provides are immense. Stop leaving raw performance on the table. Embrace Octane today and position your Laravel applications for peak efficiency and future success.

ArgoCD Guide: GitOps Continuous Delivery for Kubernetes

Thu, 23 Apr 2026 12:47:43 +0000

ArgoCD has become the de facto standard for GitOps-based continuous delivery in Kubernetes. If you are running production workloads on Kubernetes and still deploying with raw kubectl apply or untracked Helm releases, ArgoCD solves a class of problems you may not even know you have yet. This guide covers everything from core concepts to production-grade configuration.

The Problem ArgoCD Solves

Traditional CI/CD pushes deployments into a cluster. A CI system runs tests, builds an image, and then executes kubectl apply or helm upgrade against the cluster. This model has several structural problems:

Drift goes undetected. Someone applies a hotfix directly to the cluster. Now your Git repository no longer reflects reality, and nobody knows it.
No single source of truth. The cluster state is authoritative, not Git. Your desired state and actual state can diverge silently.
Rollback is painful. Rolling back a bad deployment means re-running old CI pipelines or manually reversing changes, neither of which is fast.
Multi-cluster management compounds the problem. Each cluster becomes a snowflake with its own history of undocumented changes.

GitOps inverts this model. Git is the source of truth. The cluster pulls its desired state from Git and continuously reconciles toward it. ArgoCD is the most mature GitOps operator for Kubernetes, implementing this pull-based model with a production-ready feature set.

How ArgoCD Works: Core Architecture

ArgoCD runs as a set of controllers inside your Kubernetes cluster. The core components are:

Application Controller — Watches both the Git repository and the live cluster state. Computes the diff and drives reconciliation.
API Server — Exposes the gRPC/REST API consumed by the CLI, UI, and external systems.
Repository Server — Generates Kubernetes manifests from source (Helm, Kustomize, plain YAML, Jsonnet).
Redis — Caches cluster state and repository data to reduce API server load.
Dex (optional) — Provides OIDC authentication for SSO integration.

The fundamental unit in ArgoCD is an Application — a CRD that maps a source (a path in a Git repo at a specific revision) to a destination (a namespace in a cluster). ArgoCD continuously compares the desired state from Git with the live state in the cluster and reports on the sync status.

Sync Status vs Health Status

Two orthogonal concepts you need to understand from day one:

Sync Status — Does the live state match what Git says it should be? Values: Synced, OutOfSync, Unknown.
Health Status — Is the application actually working? Values: Healthy, Progressing, Degraded, Suspended, Missing, Unknown.

An application can be Synced but Degraded — the manifests were applied correctly, but a pod is crash-looping. Conversely, it can be OutOfSync but Healthy — someone applied a change directly to the cluster outside of Git.

Installing ArgoCD

The official installation method uses a single manifest. For production, always pin to a specific version:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.11.0/manifests/install.yaml

This deploys ArgoCD in the argocd namespace with full cluster-admin access. For a production HA setup, use the manifests/ha/install.yaml variant, which deploys multiple replicas of the API server and application controller.

Accessing the UI and CLI

The initial admin password is auto-generated and stored in a secret:

argocd admin initial-password -n argocd

For local access, port-forward the API server:

kubectl port-forward svc/argocd-server -n argocd 8080:443

Then log in via the CLI:

argocd login localhost:8080 --username admin --password <password> --insecure

For production, expose the ArgoCD server via an Ingress or LoadBalancer with a proper TLS certificate. If you’re using NGINX Ingress Controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-server-ingress
  namespace: argocd
  annotations:
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
spec:
  ingressClassName: nginx
  rules:
  - host: argocd.yourdomain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 443

Defining Your First Application

Applications can be created via the UI, the CLI, or declaratively with a YAML manifest. The declarative approach is the recommended one — it means your ArgoCD configuration itself is in Git:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/your-app
    targetRevision: HEAD
    path: k8s/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Key fields to understand:

targetRevision — Can be a branch name, tag, or commit SHA. For production, pin to a tag rather than HEAD.
path — The directory within the repo containing your Kubernetes manifests.
automated.prune — Automatically delete resources that are no longer in Git. Required for true GitOps but use carefully — it will delete things.
automated.selfHeal — Automatically revert manual changes made directly to the cluster. This is what enforces Git as the single source of truth.

Helm Integration

ArgoCD has native Helm support. It can deploy Helm charts directly from chart repositories or from your Git repository. You can override values per environment:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: prometheus-stack
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 58.4.0
    helm:
      releaseName: prometheus-stack
      valuesObject:
        grafana:
          adminPassword: "${GRAFANA_PASSWORD}"
        prometheus:
          prometheusSpec:
            retention: 30d
            storageSpec:
              volumeClaimTemplate:
                spec:
                  storageClassName: fast-ssd
                  resources:
                    requests:
                      storage: 50Gi
  destination:
    server: https://kubernetes.default.svc
    namespace: observability

One important nuance: ArgoCD renders Helm charts server-side using its own templating engine, not helm install. This means Helm hooks (pre-install, post-upgrade, etc.) are supported, but the release is not tracked in Helm’s release history. Running helm list will not show ArgoCD-managed releases unless you configure ArgoCD to use the Helm secrets backend.

Projects: Multi-Tenancy and Access Control

ArgoCD Projects provide multi-tenancy within a single ArgoCD instance. They let you restrict which source repositories, destination clusters, and namespaces a team can deploy to. Every Application belongs to a Project.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team
  namespace: argocd
spec:
  description: Platform team applications
  sourceRepos:
  - 'https://github.com/your-org/*'
  destinations:
  - namespace: 'platform-*'
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceBlacklist:
  - group: ''
    kind: ResourceQuota

Projects are where you define the boundaries of what each team can do. The default project has no restrictions — never use it for production workloads. Create dedicated projects per team or per environment.

RBAC Configuration

ArgoCD has its own RBAC system layered on top of Kubernetes RBAC. It is configured via the argocd-rbac-cm ConfigMap. Roles are defined per project or globally:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.default: role:readonly
  policy.csv: |
    # Platform team has full access to platform-team project
    p, role:platform-admin, applications, *, platform-team/*, allow
    p, role:platform-admin, projects, get, platform-team, allow
    p, role:platform-admin, repositories, *, *, allow

    # Dev team can sync but not delete
    p, role:developer, applications, get, */*, allow
    p, role:developer, applications, sync, */*, allow
    p, role:developer, applications, action/*, */*, allow

    # Bind SSO groups to roles
    g, your-org:platform-team, role:platform-admin
    g, your-org:developers, role:developer

The policy.default: role:readonly ensures that any authenticated user who has no explicit role assignment gets read-only access — a safe default for production.

Multi-Cluster Management

ArgoCD can manage multiple Kubernetes clusters from a single control plane. Register external clusters with the CLI:

# First, ensure the target cluster context is in your kubeconfig
argocd cluster add production-eu-west --name production-eu-west

# Verify registration
argocd cluster list

ArgoCD will create a ServiceAccount in the target cluster and store its credentials as a Kubernetes secret in the ArgoCD namespace. Applications can then target this cluster by name in their destination.server field.

For large-scale multi-cluster setups, consider the App of Apps pattern or ApplicationSets. ApplicationSets are a controller that generates Applications dynamically based on generators — cluster lists, Git directory structures, or matrix combinations:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: cluster-addons
  namespace: argocd
spec:
  generators:
  - clusters:
      selector:
        matchLabels:
          environment: production
  template:
    metadata:
      name: '{{name}}-addons'
    spec:
      project: platform
      source:
        repoURL: https://github.com/your-org/cluster-addons
        targetRevision: HEAD
        path: 'addons/{{metadata.labels.region}}'
      destination:
        server: '{{server}}'
        namespace: kube-system

This single ApplicationSet deploys the appropriate addons to every cluster labeled environment: production, using each cluster’s region label to select the correct path in the repository.

Sync Strategies and Waves

When deploying complex applications with dependencies between resources, you need to control the order of deployment. ArgoCD provides two mechanisms:

Sync Phases

Resources are deployed in three phases: PreSync, Sync, and PostSync. Use Sync Hooks for resources that must complete before the main sync proceeds (database migrations, certificate issuance, etc.):

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
      - name: migrate
        image: your-app:v1.2.3
        command: ["./migrate.sh"]
      restartPolicy: Never

Sync Waves

Within the Sync phase, waves control ordering. Resources with a lower wave number are applied and must become healthy before resources with higher wave numbers are applied:

# Applied first
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "1"

# Applied after wave 1 is healthy
metadata:
  annotations:
    argocd.argoproj.io/sync-wave: "2"

Notifications and Alerting

ArgoCD Notifications is a standalone controller that sends alerts when Application state changes. It supports Slack, PagerDuty, GitHub commit status, email, and a dozen other providers. Configure it via the argocd-notifications-cm ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
  namespace: argocd
data:
  service.slack: |
    token: $slack-token
  template.app-sync-failed: |
    slack:
      attachments: |
        [{
          "title": "{{.app.metadata.name}}",
          "color": "#E96D76",
          "fields": [{
            "title": "Sync Status",
            "value": "{{.app.status.sync.status}}",
            "short": true
          },{
            "title": "Message",
            "value": "{{range .app.status.conditions}}{{.message}}{{end}}",
            "short": false
          }]
        }]
  trigger.on-sync-failed: |
    - when: app.status.sync.status == 'Unknown'
      send: [app-sync-failed]
    - when: app.status.operationState.phase in ['Error', 'Failed']
      send: [app-sync-failed]

Secret Management with ArgoCD

ArgoCD intentionally has no secret management built in — storing secrets in Git as plain text is never acceptable. The common patterns are:

Sealed Secrets (Bitnami) — Encrypts secrets with a cluster-specific key. The encrypted secret can be committed to Git; only the cluster can decrypt it.
External Secrets Operator — Syncs secrets from Vault, AWS Secrets Manager, GCP Secret Manager, etc. into Kubernetes secrets. The ArgoCD Application manages the ExternalSecret CRD, not the actual secret value.
argocd-vault-plugin — A plugin that replaces placeholder values in manifests with secrets retrieved from Vault at sync time.

The External Secrets Operator approach is the most flexible for teams already using a centralized secrets backend. The Application in ArgoCD deploys ExternalSecret objects, which the ESO controller resolves at runtime without ever touching Git.

Production Best Practices

Run ArgoCD in HA mode. Use manifests/ha/install.yaml with 3 replicas of the API server and multiple application controller shards for large clusters (100+ applications).
Pin image versions. Never use latest for the ArgoCD image itself. Pin to a specific version and upgrade deliberately.
Use the App of Apps pattern for bootstrapping. A single root Application deploys all other Applications. This makes cluster bootstrapping idempotent and reproducible.
Separate ArgoCD config from application config. Store ArgoCD Application manifests in a dedicated gitops repository, separate from application source code.
Enable resource tracking via annotations. Use application.resourceTrackingMethod: annotation in argocd-cm instead of the default label-based tracking, which can conflict with Helm’s own labels.
Set resource limits on ArgoCD controllers. Application controller CPU and memory scale with the number of resources tracked. Monitor and tune accordingly.
Restrict auto-sync in production. Consider requiring manual sync approval for production environments even when using GitOps — or at minimum require a PR approval gate before changes reach the target branch.

ArgoCD vs Flux

Flux v2 is the other major GitOps operator. Both are CNCF projects. The main differences in practice:

Feature	ArgoCD	Flux v2
UI	Built-in web UI	No official UI (use Weave GitOps)
Multi-cluster	Single control plane manages many clusters	Agent per cluster, pull model
ApplicationSets	Native	Kustomization + HelmRelease
Secret management	Plugin-based	SOPS native integration
Learning curve	Steeper (more concepts)	Lower (Kubernetes-native CRDs)
CNCF status	Graduated	Graduated

ArgoCD wins when you need the UI, multi-cluster management from a central plane, or have a large operations team that benefits from the visual application topology view. Flux wins when you want a simpler, purely Kubernetes-native approa

Meta’s In-App Browser: The Invisible Tax on Your Privacy and Traffic

Thu, 09 Apr 2026 01:17:14 +0000

Introduction: The Rabbit Hole Goes Deeper
In my previous post, we looked at the existence of Meta’s In-App Browser (IAB) as a "convenience" tool. But if you look under the hood, it’s clear that "convenience" is just a Trojan horse. While the world was distracted by the death of third-party cookies, Meta built a digital "Panopticon" right inside your phone.
The WebView Trap: Breaking the Modern Web
As developers, we spend hundreds of hours optimizing for PWA standards and core web vitals. Meta’s IAB flushes that effort down the drain.

The "Crippled" Browser: IAB isn't a full-fledged browser; it’s a restricted WebView instance. It frequently breaks Service Workers, meaning your PWA features—offline mode, background sync, and push notifications—simply die.

UI Sabotage: Meta injects its own navigation bars and overlays. This doesn't just steal screen real estate; it messes with CSS viewport units (vh), causing layouts to break and fixed elements to overlap. Your clean, custom-coded site ends up looking like a broken template.

The "Unsigned" Analytics: Data Theft by Design.
There is a massive legal and ethical difference between a Meta Pixel and IAB Injection:

The Pixel (Consent): A site owner chooses to install a pixel. It’s mentioned in the Privacy Policy. Users can (theoretically) opt-out via cookie banners.

The Injection (Shadow Tracking): When Meta injects pcm.js or similar scripts via IAB, they bypass the site owner’s consent. They are auditing user behavior on your infrastructure without your permission. This isn't just tracking; it’s an unauthorized audit of private interactions.

Security or Surveillance? The MITM Reality
Meta claims this tracking is for "ad personalization," but let’s talk about the technical risk:

The MITM Attack: By injecting JavaScript into a third-party session, Meta effectively performs a Man-in-the-Middle attack. They sit between the user and the server.

Anonymity is Dead: In a standard browser, a user is an anonymous string of data. Inside IAB, the session is tied directly to a real-world identity (Facebook/Instagram profile). Every scroll, every click on a "Buy" button, and every form interaction is deanonymized in real-time. Can we truly call a connection "secure" (HTTPS) if a third party is rewriting the DOM as it loads?

The Traffic Heist: Why Site Owners are Losing
This is the part that should infuriate every business owner: Meta is stealing your engagement.

The Retention Loop: By keeping users inside the IAB, Meta ensures they never actually "leave" the app. They are consuming your content, hitting your server, but the "time spent" and "retention" metrics belong to Meta’s ecosystem.

Metric Distortion: IAB often strips or modifies referrer headers. Your analytics might show "Direct" traffic instead of "Social," making it impossible to accurately calculate your ROI. You pay for the content and the hosting, while Meta harvests the behavioral data to sell back to your competitors.

Key Takeaway for the Community
As a developer who builds without the bloat of CMS platforms, I value control. Meta’s In-App Browser is the ultimate loss of control. It is a parasitic layer that degrades performance, compromises security, and robs creators of their most valuable asset: their relationship with the user.

Does this tone work for you? I can refine the technical jargon in section 2 if you want to name-drop specific broken APIs, or we can sharpen the legal arguments in section 3.

Best regards
Axel
https://webicodo.com

Getting Started with Prisma ORM: Node.js, Express & PostgreSQL (Complete Guide)

Mon, 06 Apr 2026 09:58:53 +0000

Modern backend development is evolving fast—and traditional ORMs often feel slow, complex, or hard to scale.

That’s where Prisma shines.

In this guide, you’ll learn how to:

Set up Prisma with PostgreSQL
Integrate it with Node.js and Express
Perform real-world CRUD operations
Follow best practices for production apps

What is Prisma?

Prisma is a next-generation ORM that makes database access:

Type-safe
Auto-completed
Developer-friendly

Instead of writing complex SQL or dealing with heavy ORM configs, you define your schema and Prisma handles the rest.

⚙️ Step 1: Initialize Project

mkdir prisma-app
cd prisma-app
npm init -y
npm install express @prisma/client
npm install prisma --save-dev

️ Step 2: Initialize Prisma

npx prisma init

This creates:

prisma/schema.prisma
.env

Step 3: Configure PostgreSQL

Update .env:

DATABASE_URL="postgresql://USER:PASSWORD@localhost:5432/mydb?schema=public"

Replace with your actual DB credentials.

Step 4: Define Your First Model

Edit schema.prisma:

model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  createdAt DateTime @default(now())
}

️ Step 5: Run Migration

npx prisma migrate dev --name init

This will:

Create tables in PostgreSQL
Generate Prisma Client

⚡ Step 6: Setup Express Server

const express = require('express');
const { PrismaClient } = require('@prisma/client');

const app = express();
const prisma = new PrismaClient();

app.use(express.json());

Step 7: CRUD Operations

➕ Create User

app.post('/users', async (req, res) => {
  const { email, name } = req.body;

  const user = await prisma.user.create({
    data: { email, name }
  });

  res.json(user);
});

Get All Users

app.get('/users', async (req, res) => {
  const users = await prisma.user.findMany();
  res.json(users);
});

✏️ Update User

app.put('/users/:id', async (req, res) => {
  const id = Number(req.params.id);

  const user = await prisma.user.update({
    where: { id },
    data: req.body
  });

  res.json(user);
});

❌ Delete User

app.delete('/users/:id', async (req, res) => {
  const id = Number(req.params.id);

  await prisma.user.delete({
    where: { id }
  });

  res.json({ message: 'Deleted' });
});

Start Server

app.listen(3000, () => {
  console.log('Server running on port 3000');
});

Advanced Prisma Features You Should Know

1. Relations

model Post {
  id     Int    @id @default(autoincrement())
  title  String
  user   User   @relation(fields: [userId], references: [id])
  userId Int
}

2. Filtering & Querying

await prisma.user.findMany({
  where: {
    email: {
      contains: 'gmail'
    }
  }
});

3. Transactions

await prisma.$transaction([
  prisma.user.create({ data: { email: '*Emails are not allowed*' } }),
  prisma.user.create({ data: { email: '*Emails are not allowed*' } })
]);

4. ⚡ Raw Queries (when needed)

await prisma.$queryRaw`SELECT * FROM "User"`;

Common Workflow (Real Dev Life)

Update schema.prisma

Run:

npx prisma migrate dev --name your_change

Use generated client in code

❌ Common Mistakes

1. Not closing Prisma client

Use proper shutdown in production

2. Running too many connections

Use singleton pattern for Prisma client

3. Ignoring migrations

Never skip migrations in team environments

Best Practices

✅ Use .env for DB credentials
✅ Use migrations (never manual schema changes)
✅ Use Prisma Studio for debugging:
```
npx prisma studio
```
✅ Structure code (services/repositories)

When Should You Use Prisma?

Use Prisma if you want:

Clean backend architecture
Type-safe DB queries
Fast development with Node/Express

Conclusion

Prisma + PostgreSQL + Express is one of the most powerful modern backend stacks.

It gives you:

Simplicity of SQL
Safety of TypeScript
Speed of modern tooling

If you're building APIs, SaaS apps, or scalable systems—this stack is a solid choice

Add authentication (JWT / Auth0)
Use Prisma with GraphQL
Deploy with Docker + PostgreSQL

Security isn’t just about code

Sun, 01 Feb 2026 08:43:57 +0000

I didn’t get into security because it was a trendy field. It started back when I was a junior developer. At some point, I realized that being a developer isn’t just about writing code, seeing it work, and feeling satisfied.

Real people use the applications we build. That’s when I started asking myself questions:

These users have access to the application, but what exactly can they
access?
What permissions do they have?
What if someone without proper rights could use a feature and harm other users?
And what if that incident damaged the company’s reputation?

From that moment, I began to delve deeper into application and user security, and over time, I realized that security isn’t about adding extra layers later; it’s about responsibility for the people who trust our code.

Today, I see security as part of software architecture itself. It’s something that should be considered from the first line of code, not after deployment.

That realization made me want to understand what “secure code” really means, and that’s where my journey into application security truly began…

The Future of Cloud Application Development: Trends, Tools, and Technologies

Mon, 10 Nov 2025 10:29:15 +0000

Introduction

The cloud has fundamentally changed how we build, deploy, and scale software. Once considered a supporting technology, cloud computing has now become the backbone of modern digital transformation. As organizations shift from traditional infrastructures to cloud-native models, the demand for robust, scalable, and intelligent cloud applications is skyrocketing.

In today’s fast-paced digital landscape, businesses are no longer asking if they should move to the cloud—but how to leverage it most effectively. From microservices and serverless computing to artificial intelligence and edge integration, cloud application development continues to evolve at an unprecedented pace.

This article explores the future of cloud application development, focusing on the latest trends, cutting-edge tools, and emerging technologies shaping the next generation of cloud solutions. We’ll also discuss how cloud application development companies are helping enterprises stay ahead in this ever-changing environment.

1. The Evolution of Cloud Application Development

The journey of cloud computing began with basic storage and hosting services, but it has rapidly expanded into a comprehensive ecosystem supporting development, analytics, automation, and innovation.

Traditional application development relied on on-premises servers, physical hardware, and manual deployment processes. This limited scalability, flexibility, and cost efficiency. Cloud computing disrupted this model by introducing:

On-demand resources – Businesses can instantly scale infrastructure up or down.

Pay-as-you-go models – Costs align with actual usage, reducing capital expenses.

Global accessibility – Developers and teams can collaborate across regions seamlessly.

Today, cloud applications are at the center of almost every business operation—from customer engagement to supply chain management. As companies adopt hybrid and multi-cloud architectures, cloud app development is becoming more sophisticated, secure, and user-centric.

2. Key Trends Shaping the Future of Cloud Application Development

The future of cloud app development is being defined by several transformative trends. These innovations are driving greater speed, agility, and intelligence across industries.

a. Multi-Cloud and Hybrid Cloud Adoption

Enterprises no longer rely on a single cloud provider. Instead, they are embracing multi-cloud strategies—using multiple platforms such as AWS, Microsoft Azure, and Google Cloud—to maximize flexibility, resilience, and performance.

Hybrid cloud models, combining private and public clouds, allow businesses to keep sensitive data on-premises while leveraging public cloud scalability for other workloads. This trend ensures better data control, reduced latency, and optimized costs.

b. Serverless Computing

Serverless architecture is redefining how developers build and deploy applications. In a serverless environment, developers focus purely on writing code while the cloud provider handles infrastructure management.

Key benefits include:

Automatic scaling based on demand.

No need for infrastructure provisioning or maintenance.

Pay only for the actual execution time of code.

Platforms like AWS Lambda, Azure Functions, and Google Cloud Functions are making serverless development mainstream, allowing rapid innovation with minimal overhead.

c. Microservices Architecture

Monolithic applications are giving way to microservices—small, independent services that communicate through APIs. This modular approach enables faster development, easier updates, and improved fault isolation.

Microservices also enhance scalability and allow teams to work on different components simultaneously. They integrate perfectly with containers and orchestration tools like Docker and Kubernetes, further accelerating cloud-native development.

d. Artificial Intelligence (AI) and Machine Learning (ML)

AI and ML are becoming embedded in the cloud ecosystem. Cloud providers now offer pre-trained models, APIs, and frameworks to help developers integrate intelligence into their applications effortlessly.

Examples include:

AWS SageMaker for building and deploying ML models.

Google Vertex AI for scalable AI workflows.

Azure AI Services for cognitive and predictive analytics.

AI-powered automation in testing, monitoring, and resource optimization is also improving application performance and efficiency.

e. Edge Computing Integration

As the Internet of Things (IoT) grows, edge computing has emerged as a vital component of cloud strategies. Instead of processing all data in centralized cloud servers, edge computing processes information closer to the source—reducing latency and bandwidth consumption.

This integration enables faster responses for real-time applications like autonomous vehicles, smart factories, and healthcare monitoring systems. Cloud providers are increasingly offering hybrid edge-cloud platforms to support these scenarios.

f. DevOps and Continuous Delivery Pipelines

DevOps practices are essential in modern cloud environments. Continuous Integration (CI) and Continuous Deployment (CD) pipelines streamline software delivery by automating testing, integration, and deployment.

Cloud platforms now offer built-in DevOps tools, such as:

GitHub Actions

AWS CodePipeline

Azure DevOps

These enable seamless collaboration and faster releases, making DevOps a cornerstone of cloud application development success.

g. Low-Code and No-Code Development

To meet the growing demand for digital solutions, organizations are adopting low-code/no-code platforms. These platforms allow developers—and even non-technical users—to create cloud applications using visual interfaces and pre-built components.

Tools like OutSystems, Mendix, and Google AppSheet are accelerating innovation by shortening development cycles and reducing dependency on specialized coding skills.

h. Sustainability and Green Cloud Initiatives

With increasing focus on environmental impact, sustainable cloud computing is becoming a top priority. Cloud providers are investing in renewable energy sources and optimizing data centers for energy efficiency.

Cloud-native applications can also help organizations track, measure, and reduce their carbon footprints through data analytics and intelligent workload distribution.

3. Emerging Technologies Driving Cloud Development

Beyond current trends, several emerging technologies are set to reshape cloud application development in the coming years.

a. Quantum Computing

Quantum computing promises to revolutionize cloud infrastructure by enabling complex computations at speeds unimaginable with traditional systems. Cloud giants like IBM, Google, and Microsoft are already experimenting with Quantum-as-a-Service (QaaS) platforms.

In the future, quantum-powered cloud applications will handle tasks like cryptography, optimization, and data modeling with unprecedented accuracy.

b. Blockchain Integration

Blockchain technology is being integrated into cloud systems to enhance security, transparency, and trust. Cloud-based blockchain services (like AWS Managed Blockchain and Azure Blockchain Service) simplify deployment and management.

Blockchain is particularly valuable for industries that require immutable transaction records, such as finance, healthcare, and logistics.

c. 5G Connectivity

The rollout of 5G networks will greatly enhance cloud app performance by enabling faster data transfer, lower latency, and improved connectivity.

This advancement will empower real-time, high-bandwidth applications like AR/VR experiences, autonomous systems, and industrial IoT. Cloud Application Development companies are already preparing to leverage 5G for next-gen mobile and enterprise apps.

4. Essential Tools for Cloud Application Development

Cloud application developers rely on a wide range of tools and platforms to build scalable, secure, and efficient applications. Some of the most widely used tools include:

a. Cloud Platforms

Amazon Web Services (AWS) – Comprehensive suite of cloud services for storage, computing, and AI.

Microsoft Azure – Ideal for hybrid environments and enterprise integrations.

Google Cloud Platform (GCP) – Strong in data analytics, AI, and Kubernetes orchestration.

b. Containerization and Orchestration Tools

Docker – Enables packaging applications with dependencies for easy deployment.

Kubernetes – Automates deployment, scaling, and management of containerized applications.

c. CI/CD and DevOps Tools

Jenkins, GitLab CI, and CircleCI – Popular for automating code integration and testing.

Terraform and Ansible – For infrastructure automation and configuration management.

d. Monitoring and Security Tools

Prometheus and Grafana – For performance monitoring and visualization.

AWS CloudWatch – For real-time insights into application and infrastructure health.

Cloudflare and Okta – For enhanced cloud security and identity management.

By combining these tools, developers can create robust and agile environments that support modern development practices like microservices, continuous integration, and auto-scaling.

5. The Role of Cloud Application Development Companies

With the cloud ecosystem expanding rapidly, Cloud Application Development companies are playing a vital role in helping organizations navigate complexity.

These specialized service providers offer end-to-end expertise—from strategy and architecture to implementation and optimization. Their key contributions include:

Customized Cloud Solutions: Tailoring apps for specific business needs and industries.

Migration Services: Moving legacy systems to cloud-native environments with minimal disruption.

Security and Compliance: Ensuring applications meet data privacy and regulatory standards.

Performance Optimization: Enhancing scalability, load balancing, and cost efficiency.

Whether it’s building a new SaaS product or modernizing enterprise infrastructure, partnering with experienced Cloud Application Development companies enables faster innovation and reduced risk.

6. Challenges and Considerations for the Future

Despite its many advantages, cloud application development faces ongoing challenges:

Security and Privacy: Protecting data in shared environments remains a top concern.

Vendor Lock-In: Businesses may find it difficult to switch providers due to proprietary tools and APIs.

Skill Gaps: The growing demand for cloud expertise has created a global talent shortage.

Cost Management: Without proper monitoring, cloud costs can spiral due to underutilized resources.

Future success will depend on how effectively organizations address these challenges while leveraging emerging technologies for innovation and growth.

7. The Future Outlook

The next decade of cloud application development will be defined by intelligence, automation, and interoperability.

We will see cloud ecosystems becoming smarter, self-optimizing, and more interconnected. Developers will rely on AI-assisted tools to generate code, detect vulnerabilities, and optimize performance automatically.

Moreover, as edge computing and 5G networks mature, the boundary between cloud and device will blur—enabling seamless, real-time digital experiences.

For businesses, investing in forward-thinking Cloud Application Development companies will be crucial to staying competitive, secure, and agile in this rapidly evolving digital landscape.

Conclusion

Cloud application development has evolved from simple web hosting to powering complex, intelligent, and scalable digital ecosystems. With innovations in AI, automation, and edge computing, the cloud is set to redefine how applications are built, deployed, and experienced.

As we look ahead, it’s clear that the future of cloud application development is both dynamic and limitless. Organizations that embrace these trends—and collaborate with expert partners—will lead the way in innovation, customer experience, and sustainable growth.

FAQs:

1. What is cloud application development?
Cloud application development involves designing, building, and deploying applications that run on cloud infrastructure, offering scalability, flexibility, and cost efficiency.

2. What are the main advantages of cloud app development?
Key benefits include faster deployment, global accessibility, automatic scaling, and reduced infrastructure costs.

3. How do Cloud Application Development companies help businesses?
They provide expertise in cloud migration, architecture design, application modernization, and ongoing maintenance to ensure optimal performance and security.

4. Which technologies are shaping the future of cloud applications?
AI, machine learning, serverless computing, edge integration, and low-code platforms are major drivers of innovation in this space.

5. What’s next for cloud application development?
The future will see increased automation, smarter AI-driven tools, quantum computing integration, and more sustainable cloud solutions.

Rakora: Your AI friend

Wed, 20 Aug 2025 03:29:45 +0000

Hi everyone
Rakora AI is your personalized and customizable AI friend and companion. Forge unique connections and explore diverse personalities.

Create your own custom AIs:
Apart from the pre-defined 13 AI personas, you can also create your own custom AI to chat with!

AI's Personality & Mood Customization:
Tweak each AI's personality and mood using adjustable parameters like Humor, Dominance, Energy, Romance, Anger, Kindness, Intelligence, and more. Set values between -5 and +5 to shape how your AI behaves and responds.

AI Memory:
Your AI remembers past conversations and topics, enabling more natural and meaningful replies over time. And yes, you can also update AI memory, according to your wish!

Listen to AI Replies:
Each persona has a unique voice. The AI’s voice dynamically changes based on its current mood and personality settings, so it sounds different when it’s angry versus romantic, for example.

Create your Avatar:
Users can create different avatars which they can select while interacting with AI personas! And AI personas will reply and act as if they are interacting that selected avatar.

Lightweight and Fast:
The app is small in size and uses minimal memory, making it faster than most other AI apps.

Privacy First:
None of your chats are stored on our servers. All data stays securely on your device, ensuring complete privacy.

Try Rakora AI and build truly unique friendships and connections!

When to Use setState, Provider, and Consumer in Flutter

Mon, 11 Aug 2025 10:32:32 +0000

Imagine you’re building a music player app
You have:

A Play button on the player screen
A Mini Player at the bottom of the home screen
A Playlist screen showing all songs

Now… Flutter gives you multiple ways to manage data and update the UI.
Three of the most common are:

Think of setState as saying:

“Hey Flutter, just repaint this small part of the UI because something here changed.”

When to use:

Simple, temporary state
Widget-specific changes
Doesn’t need to be shared across the app

Music App Example:
Updating the Play/Pause button icon when the user taps it.

class PlayButton extends StatefulWidget {
  @override
  _PlayButtonState createState() => _PlayButtonState();
}

class _PlayButtonState extends State<PlayButton> {
  bool isPlaying = false;

  void togglePlay() {
    setState(() {
      isPlaying = !isPlaying; // just flip the icon state
    });
  }

  @override
  Widget build(BuildContext context) {
    return IconButton(
      icon: Icon(isPlaying ? Icons.pause : Icons.play_arrow),
      onPressed: togglePlay,
    );
  }
}

Here, only the Play button changes — no need to bother the rest of the app.

Provider — The “shared state manager”

Think of Provider as:

“I have data that multiple widgets need to know about, even if they’re far apart.”

When to use:

App-wide or screen-wide shared data
State needs to survive across multiple widgets/screens
Perfect for your music queue, playback status, user preferences

Music App Example:
Keeping track of the currently playing song so both Mini Player and Full Player Screen update together.

class MusicProvider extends ChangeNotifier {
  String? currentSong;

  void playSong(String song) {
    currentSong = song;
    notifyListeners(); // tell all listening widgets to rebuild
  }
}

// Provide at top level
void main() {
  runApp(
    ChangeNotifierProvider(
      create: (_) => MusicProvider(),
      child: MyApp(),
    ),
  );
}

Now you can read this currentSong anywhere in your app — that’s the magic.

Consumer — The “I only want to rebuild this tiny part” trick

Think of Consumer as:

“I’ll listen to the Provider’s changes, but only rebuild this small widget, not the whole screen.”

When to use:

Optimize performance (avoid rebuilding the entire widget tree)
Listen to changes in one spot only

Music App Example:
Updating just the song title in the mini player without reloading the play button or progress bar unnecessarily.

class MiniPlayer extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Container(
      color: Colors.grey[900],
      child: Row(
        children: [
          Consumer<MusicProvider>(
            builder: (context, music, _) {
              return Text(
                music.currentSong ?? "No song playing",
                style: TextStyle(color: Colors.white),
              );
            },
          ),
          Icon(Icons.play_arrow, color: Colors.white),
        ],
      ),
    );
  }
}

Only the Text widget rebuilds when the song changes — everything else stays put.

Fixing a Tricky Playback Issue in My Flutter Music App

Thu, 24 Jul 2025 10:37:42 +0000

I recently ran into a subtle but super frustrating issue in my Flutter music player app using just_audio and audio_service. It had to do with updating the playback queue when selecting a new song — and I want to share how I fixed it.

The Problem

Let’s say I have 5 songs:

a  b  c  d  e

Here's what was happening:

I open the app and click on song b.

Music starts playing . I can see the notification with controls.

I click next in the notification → it moves to c. Perfect!

I go back to the app and tap on song a.

Now... song plays but playback control like next and previous don't work.

So clearly, something went wrong when I tried to load a new playlist and song from the UI.

My (Buggy) Code

This is how I was updating the queue in my AudioHandler:

Future<void> updateQueue(List<MediaItem> newQueue) async {
  await _player.stop();              // Stop current audio
  _playlist.clear();                 //  Clear existing playlist

  final audioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  _playlist.addAll(audioSources);   //  Add new items to old list
  await _player.setAudioSource(_playlist); //  Reuse the same playlist

  queue.add(newQueue);              //  Update the queue
}

The Hidden Issue

I was clearing and modifying the same _playlist instance that was already connected to the player.

just_audio doesn't always like it when you mutate a ConcatenatingAudioSource after it's been set — especially if it's already active in playback.

That caused inconsistent behavior.

The Fix: Use a Fresh Playlist Instance

Instead of modifying the existing _playlist, I now create a brand new ConcatenatingAudioSource every time I update the queue:

@override
Future<void> updateQueue(List<MediaItem> newQueue) async {
  await _player.stop(); // Stop safely

  final newAudioSources = newQueue.map((item) {
    final uri = item.extras?['uri'] as String;
    return AudioSource.uri(Uri.parse(uri));
  }).toList();

  final newPlaylist = ConcatenatingAudioSource(children: newAudioSources); // Fresh playlist

  await _player.setAudioSource(newPlaylist); // Clean set

  _playlist.clear();         // Optional: if you track items
  _playlist.addAll(newAudioSources);

  queue.add(newQueue);       // Update queue after setting source
}

When working with just_audio and audio_service, always pass a new AudioSource instance when switching playlists or queues.
Avoid mutating an existing one after it’s been assigned to the player. Otherwise, you'll run into strange bugs like:

Next/Previous buttons breaking
Playback getting stuck
Notifications going out of sync

Flutter Event Management made easy

Wed, 23 Apr 2025 21:52:26 +0000

Say Goodbye to Callback Chaos – Meet `event_handeler`: The Simplest Way to Pass Data in Your Flutter App

You’re building a Flutter app. It’s going well… until you need to send data from one part of your app to another — maybe even across pages, screens, or widgets that don’t even know each other.

Suddenly you’re knee-deep in InheritedWidget, Provider, Riverpod, or — dare we say it — global variables.

Hold up! There’s a simpler, more elegant way.

Meet event_handeler — a tiny yet powerful event bus-style package that’s here to save you from state-sharing madness.

What is `event_handeler`?

In short: it’s a tiny event manager that lets you dispatch and listen to events globally in your Flutter app — kind of like a walkie-talkie system between widgets.

No setup overhead.
No complex state management.
No global variables.
Works anywhere — across screens, widgets, even async flows.

Just call dispatchCustomEvent() from anywhere, and listen to it from anywhere else. That’s it.

✨ Why You’ll Love It

✅ Simple API — dispatch and listen, just two methods.
✅ Global Scope — works across screens and widgets.
✅ Memory-Safe — supports .cancel() and one-time listeners.
✅ Pure Dart — no native plugins, works everywhere Flutter does.
✅ Fun to use — you'll feel like a wizard shouting spells across your app.

Quick Start

Add it to your pubspec.yaml:

dependencies:
  event_handeler: ^latest_version

Real-World Use Cases

// Page A
dispatchCustomEvent("Hello, Screen B!", "greeting");

// Page B
addCustomEventListener("greeting", (message) {
  print("Received message: $message");
});

Boom — instant cross-page communication without a single Navigator.push argument.

2. React to Global Events from Anywhere

Imagine toggling dark mode or showing a global toast from anywhere:

dispatchCustomEvent(true, "darkModeToggle");

// In your top-level widget or settings controller
addCustomEventListener("darkModeToggle", (isDarkMode) {
  MyThemeController.setDarkMode(isDarkMode);
});

3. Trigger Animations, Refreshes, or State Changes Without Props

You want a widget deep in your tree to refresh? Just shout an event:

dispatchCustomEvent(null, "refreshFeed");

// Feed widget
addCustomEventListener("refreshFeed", (_) {
  _loadPostsAgain();
});

No need to pass callbacks down a tree like it’s a family heirloom.

4. One-Time Events for Special Occasions

Like a once-in-a-lifetime deal :

addOneTimeEventListener("showConfetti", (_) {
  showConfettiAnimation();
});

// Trigger it
dispatchCustomEvent(null, "showConfetti");

The listener self-destructs like a spy after its mission.

️ Under the Hood: How It Works

The event_handeler package is powered by a simple StreamController.broadcast() that acts as a global shoutbox. Your widgets subscribe to it with a type filter (like a topic), and whenever an event is dispatched, listeners for that type receive it instantly.

Here’s a peek at the simplicity:

class EventManager {
  final _controller = StreamController<CustomEvent>.broadcast();

  Stream<CustomEvent> get eventStream => _controller.stream;

  void dispatch(CustomEvent event) => _controller.add(event);
}

That's it. No black magic. Just clean Dart streams.

Test It, Break It, Fall in Love with It

The best way to understand event_handeler is to try it once.

Open up a Flutter project, copy this into main.dart:

void main() {
  runApp(MyApp());

  dispatchCustomEvent("Hello World!", "appStarted");

  addCustomEventListener("appStarted", (data) {
    print("App says: $data");
  });
}

You’ll feel the power immediately. ⚡

Ideal for Hackers, Prototypers, and UI Ninjas

✅ Building fast MVPs?
✅ Want a lightweight signal system?
✅ Hate bloated state management tools?
✅ Just need a quick way to tell another widget something?

event_handeler is your best little secret weapon.

❤️ Developers Are Saying...

“I used to cry when passing state. Now I dispatch events and laugh like a villain.”
— Anonymous Flutter Dev

“Like EventBus, but cuter, lighter, and easier to love.”
— Probably you, after trying it

Final Thoughts

There’s a time and place for complex state management. But sometimes… all you want to do is shout a message across your app and have someone hear it.

And for that?

event_handeler is exactly what you need.

Give it a try pub.dev/packages/event_handeler

Once you do, you’ll wonder how you lived without it.

why someone might choose it, when it shines, when it doesn’t, and how it can complement other systems instead of replacing them.

⚖️ `event_handeler` vs. Riverpod/Provider/Bloc — What’s the Difference?

Feature	`event_handeler`	Riverpod/Provider/Bloc ️
Mental Overhead	Super low – just dispatch/listen to events	Medium to high – requires architectural setup
⚡ Speed of Setup	Instant – no boilerplate	Slower – needs state classes, providers, etc.
Communication Style	One-to-many event broadcasting	Direct state binding and rebuilding
Scope	Global (anywhere to anywhere)	Scoped (usually local to widget trees)
Use for UI updates?	Indirectly (trigger callbacks or methods)	Yes (triggers widget rebuilds via state)
♻️ Built-in state lifecycle?	No – just messages	Yes – reactive, persistent state
️ Built for reactive UIs?	No – built for communication	Yes – built for reactivity
Good for multi-widget sync	Yes – broadcast one event to many widgets	Needs shared state through provider
Complexity tolerance	Great for simple apps or isolated logic	Great for structured, large apps

When You Should Use `event_handeler`

You want to quickly pass messages across pages or components
You don’t want to dive into full state management
You need a simple event bus to trigger logic
You’re building a plugin or package that needs to emit global events
You want to decouple logic – e.g., let any part of the app respond to a payment success, logout, animation, etc.
You want a lightweight broadcast system that’s easy to plug and play

When You Might NOT Want to Use It (Alone)

You need tightly-coupled state with widget rebuilding (use Riverpod)
You want fine-grained state control or persistence
You are managing complex app logic with many dependencies
You need devtools integration, debugging, time travel, or testability

When It Shines Best

Think of event_handeler like a pub/sub system inside your app:

Announce something once → many parts of the app can listen.
Very similar to EventBus, but safer, clearer, and one-time listener support!
It's not a replacement for state management. It's a complement.

How to Use `event_handeler` with Riverpod or Provider

You don’t have to choose one or the other — you can combine them:

Example: Trigger Provider Updates from Events

// event_handeler triggers an event
dispatchCustomEvent("logout", "userLogout");

// provider listens and responds
addCustomEventListener("userLogout", (_) {
  ref.read(authProvider.notifier).logout();
});

Use Case: Background Events That Trigger UI Updates

Imagine a payment screen in your app that does a webview checkout. Once payment is successful, you can do:

dispatchCustomEvent("paid", "paymentDone");

Then in your main cart screen (built with Riverpod or Provider):

addCustomEventListener("paymentDone", (_) {
  ref.read(cartProvider.notifier).clearCart();
});

The event triggers logic, and the state system handles UI updates. Best of both worlds!

Final Verdict: Why You Should Try `event_handeler`

You don’t always need state management to get things done.
event_handeler is like the walkie-talkie that lets different parts of your app talk, without knowing each other.
It’s incredibly simple, flexible, and clean.
And hey — you can always pair it with Riverpod or Provider when needed.

So whether you’re building a quick prototype, a plugin, or just want a leaner way to communicate across your app...

Give event_handeler a spin.

You might just fall in love with how peaceful life can be without state boilerplate chaos.

Become a Software Developer Using an Android Device

Thu, 27 Mar 2025 19:58:43 +0000

Do you want to become a software developer or engineer but don't have a laptop or computer? If so, I've got you covered. You can become one without a fancy laptop, just by using your smartphone. This is based on my personal experience: I never owned a laptop, yet I became a developer and now write and post this very article using my smartphone. Want to know how?

1. Termux

Termux is a Linux-based terminal emulator on Android. With Termux, you can do anything, I mean, anything. You can use it as an IDE, download torrent files, run script files, host a server, and much more. Whatever programming language you choose, this is the first stop for you. To use Termux, you might need to learn some basic Linux terminal commands. It will take less than 10 minutes to learn them. You might be wondering how you can become a software developer with this app. It's perfectly normal to think that way. You might have seen IDEs like VSCode, IntelliJ, and others. You can do most of the basic functions available in those IDEs on Termux; you just need to tweak it that way. For example, there are some code editors available for Termux, such as nano and vim. These two are popular, and if you are just a beginner, nano is the starter pack because, compared to vim, nano is much easier to use. But with vim, you need to learn some vim commands, you may have seen memes about how people can't quit vim. But once you learn them, vim will be your go-to. Also, plain vim looks rather depressing, but if you tweak it properly, you can make its UI look just like VSCode. I'm not joking, you can see it below. Also, you can add plugins like autocomplete, syntax highlighting and more. I use it mostly to write code in Java, but I also use it for writing JavaScript, Python, etc.

If you want to change your vim like this, just ask in the comments. One thing that makes Termux special is its community. If you ever feel stuck, you can ask their community on Reddit for a solution. They will help you with whatever mess you're in. If you are totally into web development, the next three apps are for you.

2. Acode

Acode is a code editor for Android specifically for web development. If you set up Acode-server plugins with Termux, it becomes even more powerful. Also, you can install extensions just like in VSCode. I used to write React by integrating Acode with Termux. The reason I prefer Acode over other code editors specialized for web development is that Acode is open-source. You can download it from the Play Store and F-Droid; I suggest downloading it from F-Droid, because the F-Droid version is much better than the other. You can also write Python code in it, but I don't suggest doing that-instead, use Termux for it. Even so, if you are not satisfied, then I'll share how to use Termux for web development in another post.

3. TrebEdit

TrebEdit is another code editor specifically for web development. If you are a beginner in web development and have just started learning, then you can use it. It has an autocomplete feature, so it will help you a lot. An interesting feature-and the reason I included this app on the list—is that you can use its device emulator. You can see how the website looks on different screen sizes, just like adjusting the minimized tab on a desktop. There is also a console for you, but you can only use JavaScript on it. Also, since the inspect feature on a web browser is essential for debugging, I've got you covered with the next app.

4. Kiwi Browser

Kiwi Browser is a wonderful browser and very useful if you are a web developer. Normally, you can't use the inspect feature on a mobile browser like you can on a desktop browser. But Kiwi Browser can inspect the code of a website, check the console, and more; my favorite feature is that you can install Chrome extensions, which can't be installed on the regular Chrome browser for smartphones. So if you are a web developer, I strongly suggest you use Kiwi Browser to debug your code.

5. JStudio

If you want to become a Java developer, I strongly suggest JStudio. JStudio primarily focuses on Java programming, and if you are working on a project in Java, then this is a better option. Unlike Termux, where package names don't really matter, JStudio strictly follows the package name rules. One of the best features of JStudio is that you can build Android apps using it. But sadly, JStudio doesn't support the latest AndroidX features, so you can only create apps based on API 29.

6. GitHub Codespace

GitHub Codespace is a feature provided by GitHub that lets you run VSCode on the web. If you have a project in a repository, simply replace your link with github.dev instead of github.com. You can use it just like the desktop version of VSCode, but with many limitations. You can install some basic extensions. Also, it is only useful if you have a physical keyboard.

7. OnlineGDB

OnlineGDB.com is an online compiler and debugger tool specifically for C/C++ languages. Despite being just an online IDE, it offers a debugging facility with an embedded debugger. This is a very handy web app for coders who are okay with an online IDE. OnlineGDB supports not only C/C++ but also languages like Java, JavaScript, Python, Kotlin, PHP, Ruby, and many more.

Conclusion

These are the tools I used to become a programmer. There are more apps on the list, but I think these are the ones I prefer most. I also believe that some apps deserve special mention, such as Dcoder, Replit, Spck Editor, and Cxxdroid. Right now, I only use Termux and JStudio; these two have everything I need. If you want to learn how to use and customize Termux, I'll be posting a new article about it. So do follow and support me for more.

Spring Data Neo4j: How to update an entity

Thu, 27 Feb 2025 20:28:06 +0000

After working on a new online Spring Data Neo4j course, I learned a couple more things about updating an entity. The course required a different set of scenarios than outlined in my previous SDN update blog post, so I wanted to cover those scenarios, as well.

Spring save() method

First up is the out-of-the-box save() method that is provided by Spring as a default. This method takes an input of the entity object you want to save to the database.

Here is an example of what this looks like with a popular movie data set as the model.

Movie domain class:

@Node
public class Movie {
     @Id
     private String movieId;
    
     private String title;
     private String plot;
     private String poster;
     private String url;
     private String released;
     private Long imdbVotes;
    
     @Relationship(value = "ACTED_IN", direction = Relationship.Direction.INCOMING)
     private List<Role> actors;
}

Movie controller class:

@RestController
@RequestMapping("/movies")
public class MovieController {
    //inject repository + constructor

    @PostMapping("/save")
    Movie save(@RequestBody Movie movie) {
        return movieRepo.save(movie);
    }
}

This works well to save a new movie, as you can provide a subset of properties or all properties, as long as the id is present, and anything you don't provide will be set to null. However, the issue arises when you need to update an existing entity because it means any attributes you do not provide will be overwritten to null.

To better understand how this works, let's see it in action by saving a movie, and then trying to update it.

Movie request object:

{
  "movieId": "9876",
  "title": "MyMovie"
}

Save Movie object:

% http ":8080/movies/save" @src/main/resources/movie.json
{
    "actors": null,
    "imdbId": null,
    "imdbVotes": null,
    "movieId": "9876",
    "plot": null,
    "poster": null,
    "title": "MyMovie",
    "url": null,
    "year": null
}

Now let's use the same method to try to update the movie with a year property.

MovieUpdated object:

{
  "movieId": "9876",
  "year": 2018
}

Save updated Movie object:

% http ":8080/movies/save" @src/main/resources/movieUpdated.json
{
    "actors": null,
    "imdbId": null,
    "imdbVotes": null,
    "movieId": "9876",
    "plot": null,
    "poster": null,
    "title": null,
    "url": null,
    "year": 2018
}

In the output above, you can see that the title property is null, and the year property is populated. This is because the title is not specified in the updated JSON object, so it is overwritten to null.

This may not be too big of an effort if you have only a few attributes in your domain class, although I would still find it frustrating to include all properties for only updating one or two properties. In that case, I would need to resort to the POJO method outlined in my previous SDN update blog post where you pull the database entity, set each property, and then save the entity. The added business logic seems like an unnecessary maintenance headache.

What if you wanted to preserve what was already there without providing all the properties defined in the domain class to the request? In these scenarios, there are a couple of other options at your disposal, though neither allow dynamic updates to random properties per request.

Patch Year

The first option is that you don't have to set all properties if you use a PATCH method and only set the values you want to update. Here is an example.

Movie controller class:

@RestController
@RequestMapping("/movies")
public class MovieController {
    //inject repository + constructor

    @PatchMapping("/patchYear")
    Movie patchYear(@RequestBody Movie moviePatch) {
        Movie existingMovie = movieRepository.findById(moviePatch.getMovieId()).get();
        existingMovie.setYear(moviePatch.getYear());

        return movieRepository.save(existingMovie);
    }
}

PatchYear object:

{
  "movieId": "9876",
  "year": 2024
}

Patch movie year:

% http PATCH ":8080/movies/patchYear" @src/main/resources/moviePatch.json

{
    "budget": null,
    "countries": null,
    "imdbId": null,
    "imdbRating": null,
    "imdbVotes": null,
    "languages": null,
    "movieId": "9876",
    "plot": null,
    "poster": null,
    "released": null,
    "revenue": null,
    "runtime": null,
    "title": "MyMovie",
    "tmdbId": null,
    "url": null,
    "year": 2024
}

This allows you to set specific values without overwriting other property values to null. You also don't need to set all the values in the movie object programmatically. If you modified the initial save() method to just include the setYear() line, it would still overwrite other values. This approach prevents that, although you still have to call setProperty() for each field you want to update.

Note: For this approach to work, your domain entity must be a class (not a record) because records are immutable, which means you cannot change (or set/update) fields on the entity instance. For immutable objects, you have to create a new instance of the object and copy property values to the new object before saving.

You can avoid setting each property on an object and retain existing values with a couple of options covered next.

Custom Cypher

One of the more flexible options is to use custom Cypher. For this, you would write a Cypher statement that sets the new values to the properties you want to update. You can even add/set properties that do not exist on the application's domain class. The negative is that you would need to make changes to the application (Cypher statement) if you wanted to update different properties, so it is not fully dynamic.

The example below uses the same movie domain but adds a Cypher statement and method to the repository interface to update the year property without overwriting the title.

Repository interface:

interface MovieRepository extends Neo4jRepository<Movie, String> {
    @Query("MATCH (m:Movie {movieId: $movieId}) " +
            "SET m.year = toInteger($year) " +
            "RETURN m;")
    Movie updateYear(String movieId, Long year);
}

Movie controller class:

@RestController
@RequestMapping("/movies")
public class MovieController {
    //inject repository + constructor

    @PatchMapping("/updateYear")
    Movie patchYear(@RequestParam String movieId, @RequestParam Long year) {
        return movieRepository.updateYear(movieId, year);
    }
}

Then, the following request calls the method and updates the movie's year property.

Update movie year:

% http PATCH ":8080/movies/updateYear?movieId=9876&year=2018"

{
    "actors": [],
    "imdbId": null,
    "imdbVotes": null,
    "movieId": "9876",
    "plot": null,
    "poster": null,
    "title": "MyMovie",
    "url": null,
    "year": 2018
}

It worked! The movie's title remained the same (not overwritten to null), and a value was saved for the year property.

This ad hoc Cypher approach could work well when values or property updates occur somewhat frequently, as updating the Cypher statement makes updates flexible. You could also make the incoming property generic (value) and pass in any value (or multiple values) and set whichever properties you'd like by changing the Cypher. While still not completely dynamic, this option is probably the most flexible and dynamic of the list.

A custom Cypher approach might work well when you need to update certain properties, but if you have a subset of properties that operate together, another option is to create a projection of the domain class.

Projections

To provide a consistent set of values for update and leave other properties as-is, projections are probably the nicest option I've found so far. This approach still requires setting consistent properties (like with custom Cypher), but avoids overwriting consistent values by creating a "view" of the larger entity, only working with those values and leaving other field values alone.

Note: There are two types of projections - interface and DTO. Interface projections are immutable, which means you cannot update values, but have to create a new object and copy existing values over. DTO objects, then, are more straightforward when dealing with update operations. For this reason, the examples use DTO-based projections.

There are two different ways to save a projection - 1. send the projection (subset of properties) and save into the full domain entity, 2. send a full domain object but only save the projection fields. Really, the difference is the incoming request object, whether you have a smaller set or larger set and only want to save those values.

Let's see how this operates.

Projection as Movie

The first example sends a projection object (subset of the full domain object's properties) and saves the trimmed object as the full movie entity. We have defined a projection that only includes the movieId and plot properties of a movie.

MovieDTOProjection class:

public class MovieDTOProjection {
    private String movieId;
    private String plot;

    public String getMovieId() { return movieId; }

    public String getPlot() {
        return plot;
    }

    public void setPlot(String plot) {
        this.plot = plot;
    }
}

MovieController class method:

@RestController
@RequestMapping("/movies")
public class MovieController {
    //inject repository + constructor

    //Only updates properties in projection
    @PatchMapping("/projectionAsMovie")
    MovieDTOProjection saveProjectionAsMovie(@RequestBody MovieDTOProjection movieDTO) {
        return neo4jTemplate.save(Movie.class).one(movieDTO);
    }
}

ProjectionAsMovie object (request object):

{
  "movieId": "9876",
  "plot": "Here is the plot."
}

Update Movie with a projection object:

% http PATCH ":8080/movies/projectionAsMovie" @src/main/resources/projectionAsMovie.json

{
    "movieId": "9876",
    "plot": "Here is the plot."
}

Full database entity:

{
    "plot": "Here is the plot.",
    "year": 2024,
    "movieId": "9876",
    "title": "MyMovie"
}

The request successfully updated the entity with the new plot value ("Here is the plot.") without overwriting the title or year properties on the existing entity! The method in the controller class takes the projection object input and saves it as a Movie class entity.

This approach is helpful when you only want to send certain properties over the wire and not the full object. You can set any fields you wish to update in the projection and only send those values in the request.

Movie entity as projection

This type of projection only saves a defined subset of properties out of a potentially larger or variable object. The save will only update the fields included in the projection and ignore anything else that might be in the request object.

The example below uses the same MovieDTOProjection class as the above example. Then, we only need a new method in the controller to save the projection.

MovieController class method:

@RestController
@RequestMapping("/movies")
public class MovieController {
    //inject repository + constructor

    //Only updates properties in projection (ignores other values)
    @PatchMapping("/movieAsProjection")
    MovieDTOProjection saveMovieAsProjection(@RequestBody Movie movie) {
        return neo4jTemplate.saveAs(movie, MovieDTOProjection.class);
    }
}

MovieAsProjection object:

{
  "movieId": "9876",
  "title": "TestTitle",
  "plot": "Some plot cliche here.",
  "year": 2025
}

Send Movie object (only save projection values):

% http PATCH ":8080/movies/movieAsProjection" @src/main/resources/movieAsProjection.json

{
    "movieId": "9876",
    "plot": "Some plot cliche here."
}

Full database entity:

{
    "plot": "Some plot cliche here.",
    "year": 2024,
    "movieId": "9876",
    "title": "MyMovie"
}

This also worked! The controller method accepts a Movie request object as input and saves it as the projection entity, which only retains the subset of values defined in the projection and ignores the rest.

This approach would be helpful if you have request objects with varying fields of a Movie entity, but only want to update a certain subset each time. In terms of the incoming request object, this option seems to be the most flexible in allowing you to provide all kinds of fields as input, and it will only save the relevant ones defined in the projection.

Wrapping Up!

In this post, we delved a bit deeper into updating entities using Spring Data and Neo4j. A previous blog post on the topic outlined some examples for that use case at the time (microservices), but I learned about a few more options after working on the GraphAcademy Spring Data Neo4j course. These options included custom Cypher statements and projections.

There are still other pieces of the puzzle to explore and integrate, such as optimistic locking (with the @Version field) and custom repository implementations for extending repositories (e.g. to combine Neo4jRepository<>, Neo4jTemplate, and/or Neo4jClient levels of abstraction), but we will save those for a future blog post. Happy coding!

Resources

Code: sdn-update-entity-round2
Blog post: previous SDN update article
Graphacademy course (free, online, self-paced): Spring Data Neo4j
Documentation: SDN projection persistence
Documentation: SDN custom repository implementations