Syntapse Software and Hypermedia Engineering

Component Oriented Software and Hypermedia Engineering

Frameworks encapsulate industry best practices and state-of-the-art design patterns.

Syntapse's extensive knowledge base of open source component frameworks enables us to concentrate on application specific and business logic, creating working models and prototypes to enable customer and user engagement early in your development cycle and keep them involved as the project progresses. Less coding and reinventing components means easier testing, fewer changes, and less bugs as your application evolves.

Rapid full stack protoyping using a range of high performance SSR, SEO and HMR developer friendly frameworks 

Design Agile design, continuous integration and early user engagement

Architect Solid foundations using robust open source patterns and frameworks

Engineer Building Architectures using field tested frameworks and platforms

Partner Software services ranging from analysis and design to testing and deployment

Architecture and Framework expertise committed to delivery of cost-effective, modern agile software solutions and early-as-possible iterative user engagement.

Component and Service based engineering

Software Component Engineering and Data management

Syntapse aims to design, develop and deploy cloud software according to RAD, DRY, SOLID, OOP, AOP, and FRP software design principles using enterprise grade open source platforms and standards for secure data networking and communications. These principles are embedded in our core environments: Angular, React, Vue on the front end and  Drupal, Symfony and (node.js) Express on the server. We can also provide static sites for easy cdn deployment and integrate third party libraries and frameworks.

Business and Software Services

Syntapse offers support across a range of business and software related activities from designing and delivering components to effectively and carefully managing servers and client software they are designed run on. Further details available on request.

Image result for innovation

Agile development

Software and Process Design

Website design, build and host

Software Procurement

Business microservice procurement.

Component design and deployment

Contract and license management

Prototyping

Product evaluation

Benchmarking

Quality Assurance

Multilingual Programming

Multiplatform Testing

Software integration

Software deployment

Upgrade management

Issue queue management

Core Services

We offer extensive commercial experience in complex full life-cycle agile software engineering, module and feature management, continuous integration and build automation, test driven development, software issue queues, virtual machine management, micro-service design and deployment, pattern based design, programming (dynamic, static, asynchronous, imperative, declarative, functional and reactive), concurrent and asynchronous patterns and programming, databases and cacheing, security: authorisation and authentication, component life-cycles, debugging, error handling and reporting.

Why choose Syntapse?

  • We have spent over a decade gaining a deep understanding of web based applications, protocols and technologies.
  • We offer expertise in the core patterns, frameworks and libraries being used to build the modern web.
  • We support the best open source and industry leading solutions available.
  • We minimize technical debt and complexity by adding only the business logic your business needs to established, tested frameworks.
  • We can develop flexible systems to meet and future proof business processes and are not limited to a single platform or language.
  • Library, service and resource discovery is an integral part of our design philosophy to keep things as DRY as possible.
little people cogs

SOLID Engineering principles

Single Responsibility Principle

A class should have one, and only one, reason to change.

When requirements change, this implies that the code has to undergo some reconstruction, meaning that the classes have to be modified. The more responsibilities a class has, the more change requests it will get, and the harder those changes will be to implement. The responsibilities of a class are coupled to each-other, as changes in one of the responsibilities may result in additional changes in order for the other responsibilities to be handled properly by that class.

 Open-Closed Principle

You should be able to extend a classes behavior, without modifying it.

 

This principle is the foundation for building code that both open and closed.

  • Open for extension: This ensures that the class behavior can be extended. As requirements change, we should be able to make a class behave in new and different ways, to meet the needs of the new requirements.

  • Closed for modification: The source code of such a class is set in stone, no one is allowed to make changes to the code. Abstractions and Generalisations enable the programmer to extend the behavior of a class without changing a single line of code. For example, Circles and Squares can be programmed as shapes. Then, wherever we had Dependency Injection, we would inject a Shape instance instead of an instance of a lower-level class. This would give us the luxury of adding new shapes without having to change the dependent classes’ source code.

 

Liskov Substitution Principle

Derived classes must be substitutable for their base classes.

We have a Rectangle a Square class that extend its. Rectangle has two methods, setWidth and setHeight set the width and height of the rectangle respectively. The problem is that the behavior for the two methods differs between the Rectangle and the Square classes. The reason for that is that a Square, by mathematical definition is a Rectangle with equal height and width. So, the two methods will change the same value, whereas for the Rectangle, they will change the width and height respectively, which are different values from each other. When we are using abstraction(Open-Closed Principle), we want the methods to behave the same for each derived class, and not differently. Square class should not be extending the Rectangle class, because the behavior of the inherited methods differs.The solution is to design by contract. What this means is that each method should have preconditions which must hold true in order before a methods executes and post-conditions after the execution of a method.

 Interface Segregation Principle

Make fine grained interfaces that are client specific.

Let’s say we had an interface called Animal, which would have eat, sleep and walk methods. This would mean that we have a monolithic interface called Animal, which would not be the perfect abstraction, because some animals can fly. Breaking this monolithic interface into smaller interfaced based by role, we would get CanEat, CanSleep and CanWalkinterfaces. This would then make it possible for a species to eat, sleep and for example fly. A species would be a combination of roles, instead of being characterized as an animal, which would not necessarily be the best description. At a larger scale, microservices are a very similar case, they are pieces of a system separated by responsibilities, instead of being a great monolith. 

 Dependency Inversion Principle

Depend on abstractions, not on concretions.

By dictating that both high-level and low-level objects must depend on the same abstraction, this design principle inverts the way some people may think about object-oriented programming.  By depending on higher-level abstractions, we can easily change one instance with another instance in order to change the behavior. Dependency Inversion increases the reusability and flexibility of our code. This principle is defined easiest by two rules:

  • High level modules should not depend upon low level modules. Both should depend upon abstractions.

  • Abstractions should not depend upon details. Details should depend upon abstractions.

The idea behind points A and B of this principle is that when designing the interaction between a high-level module and a low-level one, the interaction should be thought of as an abstract interaction between them. This not only has implications on the design of the high-level module, but also on the low-level one: the low-level one should be designed with the interaction in mind and it may be necessary to change its usage interface.

curcuit board

Rapid Application Development (RAD)

Syntapse has a familiarity with RAD principles dating back two decades. Modern developer communities are increasingly creating web applications using RAD techniques. Numerous CASE-type products (for example, application program interfaces) are available that developers can use to combine pre-designed object-oriented functions to form unified applications. This website has also been constructed from such a set of tools.

little people cog

Don't Repeat Yourself (DRY)

Don't repeat yourself (DRY) is a principle aimed at reducing repetition of software patterns replacing it with abstractions or data normalization to avoid redundancy. The DRY principle is: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". It applies equally to all aspects of software, test and documentation. When the DRY principle is applied modification of any single element of a system does not requires changes to other logically unrelated elements.

robot arm

Object oriented Programming (OOP)

Syntapase has over two decades of experience working with Object-oriented programming (OOP): is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields ( often known as attributes) and code, in the form of procedures and functions, that mutate the data. OOP is the basis of modular programming and code reuse. A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self"). In OOP, computer programs are designed by making them out of objects that interact with one another. OOP enables reuse and is complementary to both AOP and FRP paradigms. All of Syntapse's supported languages are object oriented at their foundations and rely on the same modular programming principles.

glass molecule

Aspect Oriented Programming (AOP)

Aspect-oriented programming (AOP) entails breaking down program logic into distinct parts (so-called concerns, cohesive areas of functionality). Nearly all programming paradigms support some level of grouping and encapsulation of concerns into separate, independent entities by providing abstractions (e.g., functions, procedures, modules, classes, methods) that can be used for implementing, abstracting and composing these concerns. Some concerns "cut across" multiple abstractions in a program, and defy these forms of implementation. These concerns are called cross-cutting concerns or horizontal concerns.

paragraph entity

We committed to open source and are happy to become your partners in open source adoption.

Register your interest for updates.