JavaScript

Syndicate content 14 

So, one day you're working away at WidgetsDirect, the leading supplier of widget and widget accessories, when your boss asks you to develop the new customer facing portal to allow the client base to access the next generation of Widgets..... and he wants you to use Angular 1.x to read into the department's Caché server.   

There's only one problem:  You've never used Angular, and don't know how to make it talk to Caché.

This guide is going to walk through the process of setting up a full Angular stack which communicates with a Caché backend using JSON over REST.  

Last comment 25 April 2019
+ 14   1 7
2743

views

+ 14

rating

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. In the previous part, we created a basic front-end React application. In the second part of this article series I will show how to choose the right back-end technology for your application. You will see Caché allows you to use many different approaches to link your front-end to your Caché server, depending on your application's needs. In this part we will set up a back-end with Node.js/QEWD and CSP/REST. In the next part we will enhance our basic web app and connect it to Caché using these technologies.

Last comment 14 December 2018
+ 5   0 4
2164

views

+ 5

rating

Full-Stack JavaScript development allows you to create state-of-the-art applications with Caché. With any (web) app you build nowadays, one has to make a lot of architectural decisions and you want to make the right ones. With the Node.js connector available for Caché, you can create a very powerful server side application server, allowing you to use the latest JavaScript technology and frameworks client- and server-side.

With all these new technologies, the most important is to integrate them in the most efficient way and to create a very productive development experience. This article willl get you started step-by-step with Node.js technology.

Last comment 21 October 2018
+ 9   1 7
1680

views

+ 9

rating

or "Bonus Breakage"

In our last lesson, we added a relationship between 2 persistent classes.  We are clearly going to need to start creating REST Services to expose CRUD operations for each of these classes, but before we do that, we should really finish defining our linkages.  We added code to our Widget toJSON to spool off related Accessory data, so we should really do the reciprocal and allow Accessories to return all Widgets that are compatible.

Last comment 24 September 2018
+ 3   1 2
571

views

+ 3

rating

or "Didn't you say you would cover Persistent Objects in Part 5, Chris?"

Yes, that was the plan.  This is a pretty important topic, so it get's its own Article

Up until now, we've display widget JSON that has been created by a basic loop.  Clearly this isn't of much value.  Now we have our stack connected together, and we can see that the data is flowing to the Welcome page, it's time to complete the stack and start feeding our service from "real" data.

Last comment 4 July 2018
+ 2   0 3
872

views

+ 2

rating

One of the most important features during application development is the ability to debug your code easily. Because of the asynchrnous nature, a standard Node.js application server works single-threaded by default. When you are developing applications using an IDE like Visual Studio Code, you can very easily debug your Node.js process:

First, download the free Visual Studio Code IDE (@code) and install it on your development machine.

+ 3   0 2
0

comments

1079

views

+ 3

rating

I've mentioned the QEWD project in this group before: it's a Node.js-based platform for web, Native and REST applications which tightly integrates with Cache.  It uses a somewhat different philosophy to the use of Node.js than the norm, and I've now published an article that explains this approach and the unique benefits that arise as a result.

It turns out that, integrated via QEWD, Cache is an ideal bed-fellow for Node.js.  QEWD makes the integration of Cache and Node.js exceptionally fast, simple and intuitive to use, but also extremely powerful.

Read the article here: 

Last comment 25 September 2017
+ 4   0 4
335

views

+ 4

rating

In my previous posting about the new support in QEWD for JSON Web Token (JWT) support, I mentioned that it was a key step in enabling Micro-Service support in QEWD.  In this post I'll give some background to how they work and the thinking behind them.

If you haven't heard about Micro-Services and/or want to learn more, there's lots of information available if you do a Google Search.  Here's a good starting point:

https://smartbear.com/learn/api-design/what-are-microservices/

Last comment 5 September 2017
+ 3   0 3
379

views

+ 3

rating

 

Quite a few enhancements have appeared over recent months in QEWD for easing and simplifying the creation of REST-based services.  It's now even more slick and powerful,  allowing you to very quickly create very high-performance, highly-scalable REST (and Web) services that make use of Cache.

I've therefore updated the training presentation deck (Part 31 on developing REST Services with QEWD).  It describes all the new features with worked examples.  See:

Last comment 17 August 2017
+ 2   0 4
342

views

+ 2

rating

Developing a Full-Stack JavaScript web app with Caché requires you to bring together the right building blocks. Previously, I outlined the basic steps to install and connect Node.js to Caché and make it's powerful multi-model database capabilites available for use with Node.js. You can use Caché as a NoSQL-, document- (with unique key-level access!), SQL- and object-database with Node.js. When developing JavaScript applications, you'll see how powerful this combination is and makes Caché a perfect fit for Node.js.

In the first part of this article series I will show how to get started with the React framework, one of the most popular frameworks currently taking over front-end development. In the next parts you'll learn how to connect a basic web app to a Caché back-end.

You'll see, it's very easy to get started with this technology - you can even compare the amount of basic knowledge you need to COS because you only need to know a few basic concepts to start!

Last comment 8 August 2017
+ 8   1 13
3433

views

+ 8

rating

or "Things are going to break"

We left our application over the weekend, secure in the knowledge that it was returning data from our primary persistent class, User.Widget.  However, Widgets Direct are the premier supplier of both Widgets AND Widget Accessories, so we should really start working on adding these Accessories to our application. 

Last comment 5 June 2017
+ 2   0 0
716

views

+ 2

rating

About the Ontodia library

First of all, I think we should provide some background information about Ontodia and Caché DBMS. Let’s start with a less known product, Ontodia. Ontodia is the result of a joint project of the ISST lab of the ITMO University and VISmart, a software development company specializing in the semantic web domain. The Ontodia service was created as a web application for visualizing linked data and ontologies.

Last comment 16 May 2017
+ 4   0 0
512

views

+ 4

rating

Something that shot up the popularity stakes last week was this article on a very interesting initiative: RealWorld:

https://medium.com/@ericsimons/introducing-realworld-6016654d36b5

I decided it would be a good idea to use this as a way of creating an exemplar implementation of a RESTful back-end using QEWD against their published API (https://github.com/gothinkster/realworld/tree/master/api)

The results are here:

Last comment 11 May 2017
+ 4   0 0
946

views

+ 4

rating

In our last lesson, we added some formatting and validation to our Edit Widget form.  So, now we are ready to add the ability to add new Widgets to our application.  However, the great Widget Wars have come to an abrupt end, as Widget Direct has purchased its biggest competitor, WorldWideWidgets.  In order to maintain some continuity, we need to display their catalog on our new application.

+ 2   0 2
0

comments

385

views

+ 2

rating

In our last lesson, we added a form to Edit our existing Widgets, and save them back to the server.  However, our Form was not well structured and our Save button had no intelligence, and was not fully visible.  So today, we will apply some Material components and Angular style to make the form more useful

+ 2   0 4
0

comments

377

views

+ 2

rating

We finished our last lesson with our Widgets Direct page iterating over a list of widgets, displaying an ID and a Name value.  While we have been able to achieve this with only a small amount of coding, the page itself is not the most visually appealing place to be.  The AngularJS framework is providing a powerful Model-View-Controller framework for our structure and logic, but it does not implement anything that will provide a nice UI experience.

Last comment 25 April 2017
+ 6   0 5
912

views

+ 6

rating

At the end of our last lesson, we ended with our page displaying a nice (but garish) Angular Material Toolbar, and our Widget data displaying in a list of Material cards.  Our page feels a bit static, and we already know that the large number of Widgets that we will be dealing with will not be especially usable on a static list.  What can we do to help?

+ 3   0 0
0

comments

650

views

+ 3

rating

or "So you just got yelled at by your boss, for sending him an unformatted Hello World webpage"

Our previous lesson ended with us serving a Message value obtained from a Caché REST service to the client, using Angular as a runtime.  While there is a lot of moving parts involved in this process, the page is not especially exciting at the moment.  Before we can start adding new features, we should take a step back and review our tools.

+ 11   1 6
0

comments

1278

views

+ 11

rating