Mendix Overview

Overview: Mendix is a market leader in low-code app builders. While I predominantly use the Power Platform, Mendix can be a good option.  

The ALM has Version Control. This is intuitive and follows a local checkout version commit back to a main branch (simple version control). It allows you to use branches so comprehensively and flexibly. Checking in small and often is a good idea, or you run the risk of large, complex competing merges. I believe it is git, but from the Mendix Studio Pro IDE, it is seamless.  

Build a local Version using Mendix Studio Pro and deploy it to the cloud. There are several options, including on-prem. The free version is basic and has limitations, but it has proven helpful for learning.

Note: There is also a Mendix Studio (Not Mendix Studio Pro) but it is hardly used by anyone.

Mendix supports sprints and boards, so you can work with User Stories in the Developer Portal for ALM.

An App Package can be stored, and it is a good idea to use this as the base for all projects in your company so that basic branding and naming conventions are consistent.

Deployment anywhere such as on-prem. via Kubernetes deployment, as well as the major cloud platforms i.e. AWS, Azure, GCP, Oracle.

Marketplace - templates, connectors, and components to reuse. 

Domain Modelling is excellent. When creating an app, you can choose your database (not the canned version). Modelling and exposing via OpenAPI contract and generating CRUD screens are easy. 

Get Data Options

Types of Data Sources available in Mendix.

Logic/Programing: In Mendix, we use flows for logic; there is no programming language.

• Microsflows - Server-side logic.
• Nanoflows - Smaller basically client side (think JavaScript logic)

Tip: The variable state is typically stored within the local Postgres database for later use.

Publishing to cloud production versions is very easy, and the local version, which is being developed, is seen on localhost. Mendix has simple, great built-in source control.

Image 1. A high-level overview of the logical components making up Mendix.

Pros:

1. Easy to use.
2. The basics for Low code are included, such as version control, project management, and deployment/publishing.
3. Build native mobile apps.
4. Improve business processes efficiently.
5. Supporting multiple languages is unbelievably simple and easy.

Image 2. Add multiple Languages to your app

Simple exercise: Call a key-secured API and display it on a Mendix page after watching this 7-minute video on API Calls.

The running example has:

1. Various pages and forms show and persist database information. 
2. A REST Call to a 3rd party using the OAuth key.  
3. Publishing a REST API based on a table and an associated entity.
4. Displays an Azure Chatbot

Me playing around with a Mendix App:

1. Get a REST endpoint and verify using postman (using a key for secure access)

Image3. Postman showing the REST call to be used

2. Create a new "microflow" as shown below:

3. Add a new "Action" of type "REST Call"

4. Add a JSON Structure file

5. Decide which attributes to pull out

6. Create an "Entity" in the Domain model to hold the retrieved data.

7. Map Model to the Import as shown below

...

Mendix Series

1.  Overview of Mendix (this post)

2. Mendix - Part 2 - Diving deeper

3. Extensibility for Mendix Studio 

4. Building a Mendix Widget for the Mendix marketplace (Convert text to Audio using Azure AI)

5. Mendix Tips & Thoughts

6. Competitors

Setup access for the Power Platform API using a Service Principal (secret)

 Overview: I had a hard time setting up my tenant to use the Power Platform API, so here are my notes.

1. Register a new App that will be the Service Principal (SP)

Open https://portal.azure.com and login, and open your Azure Active Directory (mine is Radimaging Ltd) > Click "App Registrations" > "New registration" > add the registration as shown below:

Click the "All applications" tab and verify that the SP has been created.  Click the application to go into it.  Mine is called "Power Platform SP".

2. Give the SP permissions to use the Power Platform API's

Click "API permissions" > "Add a permission" > select the tab "API's my organization uses", search for the "Power Platform API" ensure it has the Application(Client Id) of "8578...".  

    Optional: If the API does not show up, use Power Shell to add it. 

Add permissions.  These are the permissions I added:

Click the "Grant Admin consent for ..." I did this but not sure if it is needed.

I also change the authentication setting on the SP to "Allow public client flows"

3. Use postman to check you are generating the Access token

API Economy Technology Breakdown for Strategy Leadership

 

XaaS - Everything as a Service.  Objects can be used as a service e.g. renting cars by the hour

CX - Customer Experience

App Insights - Website and API Monitoring

Overview:  App Insights has functionality to run scheduled web requests and log the output in App Insights.  There are multiple advantages to this including end to end active monitoring of web sites and API's, and keeping the application warm.

Below I show a simple request to my blog (public website) and the results, Azure refers to this test type as a URL Ping test which is basically a URL HTTP GET request.  

Wait a few minutes and Refresh to see the results:

Very easy way to include a constant check that your API or Website is running.  There is also the options to create "Multi-step web test" using Visual Studio.  You can record the authentication and assert for known response content to build advanced constant monitoring.

Tip: The URL does need to be publicly available.

The content I used to test out the functionality comes from the Microsoft Docs site.

Also see Live Metric Stream that is part of App Insights.

Monitoring using Azure Monitor Dashboards:

• The image above shows a dashboard that can be used to monitor a SaaS applications PaaS Infrastructure.
• It's a good idea to create multiple dashboards and they can show the overview and allow the user to drill into specific areas.
• Internal boards watching key API's, HTTP uptime ping type requests is also a good idea.

Updated: 11 Jan 2023 - Checkly looks like a great monitoring service that works with Playwright for continuous monitoring.  I like to keep all my SaaS on Azure, but Checkly is independent an as it is monitoring.

More Info: 

App Insights MultiStep Tests  Replacement Option for MultiStep Test based on Azure Functions

Options Layering API's on Data Sources - Micrososervices kind of

Hasura takes data sources such as SQL, Postgress & MySQL and converts it into GraphQL API's.  SQL Server is in preview.  Service is available on Azure and hooks into AAD and AAD B2C.  Hasuru looks extremely interesting and useful.  Potentially a great time saver.

CDS/DataFelx/Oakdale - Allows for Entity creation and provides REST API's.

SharePoint lists provide HTTP API's for CRUD operations.

REST API's vs GraphQL

OpenAPI specification (previously known as the Swagger specification) is my default for an API, this allows for a known RESTful API that anyone with access can use.   Open API has set contracts that returned defined objects which is great, you can work with the API like a database with simple CRUD operations as defined by the specification.  The issue is that the returned objects are fixed in structure so you may need 2 or more queries to get the data you are looking for.  Alternatively, GrapghQL allows the developer to ask for the data exactly as the want it.

Open API example:

/api/user/{2} returns the user object  // Get the user object for user 2

/api/users/{2}/orders/10  // Returns the last 10 orders for the user

GraphQL example:

Post a single HTTP request.

query {

 User(id: "") {

    name

    email

    orders(last: 10 {

      orderid

      totalamount

      datemodified

    }

 }

} 

Database Option Notes:

PostgreSQL - Hybrid relation database (Communitity edition free, standard and enterprise higher loads) sits on Linex but can also use Windows OS.  Replicas are used for additional read-only nodes (I think up to 5 geo relicas allowed) 

Can be hosted on Azure or AWS IaaS.  PostgreSQL is also offered as a fully managed service (PaaS) on Azure (either single server or hyperscale).

MariaDB community fork off MySQL - Open source relation database used in the LAMP app stack.  Azure MySQL manage service can have up to 5 replicas for read heavy workloads.

OpenAPI Tooling working with WebAPI and APIM Notes

Editor.swagger.io is a great tool for building OAS files.  The Swagger editor is easy to use and has a preview for changes.

VS Code is a great IDE for working with OpenAPI  specification 2.0 and 3.0 files (also know and Swagger specification).  These 3 extensions are a good idea for working with a OpenAPI specification file.

Spotlight also has an editor which is nice.  Takes a little bit of getting use to, but make complex API design first easier.

Designing an API with Web API on Azure

.NET core is great for creating a Web API project to provide an API.
Tip: Swagger is a great tool that has an editor to specify your API.  With the OpenAPI specification for your API, you can generate documentation, or use the code generation feature to generate tests or C# code.
Tip:  Use the Swashbuckle.AspNetCore Nugget package to generate an OpenAPI specification for your API if you use a code first approach.

Do not trust incoming parameters, you must validate.  Always respond with generic header error messages so you don't give away back-end information.  Ensure you log all errors and review them.

Preferred High Level Design I like for Web API projects

The API needs to return Status Codes to allow consumers/clients to know how there operations are doing so I design with these standard HTTP status codes:

CodeCode Status Meaning 200 OK (GET) 201 Created (POST or PUT) 202 Accepted.  Used for long running operations. 204 Resource has been deleted (DELETE) 304 Not Modified 400 Bad Request 401 Not Authorized 403 Forbidden 404 Not Found 422 Entity Validation Issue 429 Too many Requests (Implement at APIM layer only) 500 Internal Error

• The bold codes are the three minimum set of response codes I will use for a simple API.  The next 4 most important are italicized.
• Name resources/EndPoints with nouns and I always use lowercase e.g. /api/customers is better than verb noun which was common a few years ago, e.g., /api/GetAllCustomers  NB!  No verbs in URL naming.
• Keep the URL's simple.
• Always use HTTPS.
• DateTime data is always in UTC.
• Sensitive information must be in the header or body, not in the URL as it is not encrypted.

URL/Resource	GET (read)	POST (create)	PUT (Update)	DELETE (Delete)
/customers	List all customers	Add/created a new customer	Bulk update customers	Bulk Delete or Generally error and don’t implement
/customers/35	Get a specific customer.  Customer 35 is John Doe	NA	Update the John Doe record	Delete the John Doe object/record

HTTP Methods to Support

GET	Return the current value of an object
PUT	Replace or update an object
DELETE	Delete an object
POST	Create a new object.  Return 201 for created and 202 for long running operations.

* PATCH - is also used for updating objects but normally a subsets of existing data

Versioning
API's need to change but there can be multiple client applications consuming my OpenAPI.  We use versioning to ensure I don't break existing implementations.  There are different strategies for versioning API's:

• No versioning:   https://pbeck.co.uk/customers/35
• URI versioning: https://pbeck.co.uk/v2/customers/35
• Query string versioning: https://pbeck/customers/35?version=2
• Header Versioning:  Not in the URL but passed in the header (my preferred option)

APIM has a great implementation for versioning.  Generally, adding optional data is pretty safe for API versioning.  You need to give 3rd parties using your API's time to implement the new version before deprecating and versions.

Tip: Enforce versions are present in the header.  No version return bad request.

JSON
JSON property names SHOULD be camelCased.

Query Params

Allow filtering using query param e.g. https://pbeck.co.uk/customers?firstname='paul'

Allow sorting for the most common properties

DateTime should be in UTC - The pattern for this date and time format is YYYY-MM-DDThh:mm:ss.sTZD. It is recommended to use the ISO-8601 format.  UI does adjustment for local time display.

Paging

Requests must have max return limit e.g. 100 items.  Specifying the limit param if you want to change the size of the dataset to return.

CORS

Cross Origin Request will need to be supported, reply on OAuth for who can use the API.

HATEOAS 

Good way to navigate around your API.  And a principle worth adhering to where possible.  

Authentication and Authorization

API's access should be via OAuth2.0.  It is very easy to hook APIM and underlying App Service (Web API) up to AAD B2C.  Scopes are used for authorization.

Code Review/Quality

"Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter)".   Examples of Linting Tools are Resharper, StyleCop, SonarQube, ...

Security

Always review the OWASP API Security for your API's.

https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
https://owasp.org/www-project-cheat-sheets/cheatsheets/REST_Security_Cheat_Sheet.html

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

It's a good idea to also have a WAF in front of your API.

DevOps Tooling

DevOps Tooling Notes

DevOps Tooling is broken down into the following areas, note the tools often overlap in function.  The list is not exhaustive but these are the more common tools I have come across.

1. Version Control: TFS, Git, SVN, ...
2. Bug Tracking: ServiceNow, Jira, ZenDesk
3. Continuous Testing: Selenium, Jasmin or Mocha or Unit.js (JavaScript testing), NUnit, Web Tests (Visual Studio), SpecFlow
4. Continuous Integration (CI): TeamCity, Jenkins, Azure DevOps (bigger) 
5. Configuration Management and Deployment:  Puppet, Chef, ANSIBLE, SALT  (all installed on Linux, obviously work on Windows environments)
6. Containers: Docker, Kubernetes, Microsoft Containers. I think the Azure AKS is pretty much containers for Azure now.
7. Other:  PowerShell, VMWare, HyperV

RESTful API Tooling

1. Swagger - awesome.  Swagger is a set of tools that help document, build and test your API  (Your API conforms to the OpenAPI specification or Swagger specification).  Great way to get a contract for users of the API early on.  Updated 2019/11/25:  Link to Swagger post
2. Swagger UI, Swagger Integrator,...
3. Apiary - UI to create an API and publish with mocks.  I prefer Swagger or on simple projects APIM.
4. API Management (APIM) - flexible Azure service for bring together multiple API securely.  Same as MuleSoft.  Can import OpenAPI's v2 or v3 to create a hosted API.  Can mock and built in test tool.
5. RAML is an alternative to Swagger and Apiary (never used)
6. Blueprint - API documentation tool.  Pretty simple and nice results.
7. Postman - send http requests to the API.  Postman is a REST client useful to check your API.  This is my main tool for testing, exploring REST based API's.  
8. SoapUI - if working with SOAP/XML.
9. Slate - API documentation - I always use OAS/OpenAPI/Swagger.
10. Fiddler - I'm old school and still love Fiddler and it's capabilities.  Fiddler is a great HTTP debugger.  
11. BURP - an HTTP debugger to review traffic.  I've used BURP for security testing and it is great for API debugging.  
12. Charles is another HTTP debugger (never used).
13. cURL - Cmd line to test API's using HTTP, separate exe to run on Windows, Windows 10 has cURL built in.
14. Visual Studio
15. Wireshark - Over the years I have needed packet sniffing to fix issues and always go to Wireshark, I used the tool in the 90's but it had a different name.  Extremely useful for issues relating to firewalls, especially when an environment reacts differently to another working DTAP environment.
16. Tcpdump is another packet sniffer

Testing:
http://www.incyclesoftware.com/2014/02/executing-selenium-ui-tests-release-management/

More Info:
http://blog.sharepointsite.co.uk/2014/02/devops-and-sharepoint.html
http://www.networkworld.com/article/2172097/virtualization/puppet-vs--chef-vs--ansible-vs--salt.html
http://blog.sharepointsite.co.uk/2013/11/iac-presentation-for-sharepoint.html