Building Modern Websites using "Legacy" technology

Wednesday, January 10, 2018

We're kicking off the new year at Endpoint Systems with a new project that we think will help further drive the public dialog around Web and API technologies. We're doing this for a number of reasons; first and foremost, we think we've found a unique opportunity to build a data-driven website that will provide significant value to end users as well as a wide array of vendors. In fact, we think it's such a great idea that we're going to keep the idea itself under wraps. That being said, we think the discussion around our unique implementation of this idea needs to be shared among technology peers and vendors.

We want to start by outlining our strategy around Web and API development. Let's start with a simple mission and then discuss the reasoning behind it.

Our Mission

  • To build fast, efficient web and API applications using (primarily) .NET and other tools, with a bias toward machine code but examining ways to leverage Javascript
  • To store our data using XML using the various standards, tools, and libraries at our disposal
  • To render markup that is fast and SEO friendly
  • To build APIs that play nicely with JSON, XML, and other formats
  • To build HIPAA and NIST-compliant apps and platforms

Our Approach

Our go-to choice for this is the Nancy framework, a lightweight, low-ceremony framework for building HTTP-based services on .NET and (coming soon) .NET Core. We prefer pairing it with OWIN, as it gives us a highly extendable platform for building just about anything.

Our other go-to technology for building our apps is our own https://bdbxml.net database library. Figaro extends the Oracle Berkeley DB XML serverless database engine into .NET and gives developers a high-performance data storage option using - you guessed it - XML and related technologies. We're also going to build a view engine for our web apps using XQuery, a standard long-abused and neglected by major software vendors as a means to storing structured data in relational storage.

We're going to explore different UI options as well. Currently, our favorites are ZURB Foundation and jQuery UI, but given the plethora of other options, we will consider others as we encounter ways to introduce and demonstrate them. Our ultimate goal, however, is to maximize the capabilities of CSS and HTML5 while minimizing any Javascript involvement in our applications.

At first glance, this may seem counter-intuitive - especially given all of the inroads to web application architecture using React, Angular, and other frameworks. We contend that we can still build great applications that perform faster and more efficiently without them. We also see grave potential security risks around the NodeJS module stack, and given some of the data breaches we've seen in the past year alone, we want to make sure we do everything we can as a HIPAA consulting service to avoid that.

Web and Data Formats

Over the past several years, JSON has become the defacto web data format for just about every conceivable data structure passed throughout web applications and APIs. Many reasons for this don't necessarily need repeating - it's lightweight, compact, and a native datatype to an increasingly Javascript-driven web. In most cases, it's a simple version of what you need to get things done quickly. But before JSON became synonymous with web development, XML drove business data standards, many of which remain in effect today. So while the web may run on JSON for most things, most businesses still require XML in one form or another.

We've made this case before - the JSON and XML formats complement each other. A simplified narrative to our general approach is this:

  • XML for data storage, documents, and large datasets
  • JSON for web communication and integration
  • YML for configuration

This approach is mostly in line with most current web platforms; the only one that seems to get no love, so to speak, is the XML part.

JSON has become such a panacea in the Web/API space that even Google and other search engines are asking for JSON-LD data as a recommended data structure in web pages. Only in search engine land does it make sense to shove a non-markup data structure into a markup document. We think web development can do better with its structured content and microdata.

Security

Our go-to product for web app security is Azure Active Directory Business-to-Consumer, also known as Azure AD B2C. It's a cloud identity management tool for web, mobile, and other applications (it can even be used for desktop apps). It's highly global, scales to millions of identities, and best of all it is highly secure - no more databases full of insecure passwords and worse, personal data.

Stay Tuned

We'll post more updates, so feel free to track our RSS feeds for the Endpoint Systems blog as well as for the Figaro blog. You can also track our GitHub repositories at https://github.com/endpointsystems and https://github.com/bdbxml , respectively. You can also feel free to reach out to us on our Slack channel at https://bdbxml.slack.com/ .