Architecture of Apigility - api

I have several Systems under different subdomains working. Every system serves some Restful APIs, which are used by mobile clients.
Now I looked at apigility for managing those APIs.
But the architecture is not completely clear to me. All of my systems serving APIs are built with Zend Framework 2.
Will I have to add to every system the apigility component? Or can I set up another subdomain where I will use apigility? Can I there configure the APIs for all systems from one place? Or will I have to configure the apigility for every system seperate?
It would be nice for me, if I can access apigility under api.example.com and then see the different APIs of the systems I have configured. The APIs will be served under the subdomains of the system, for example:
system1.example.com/api/documents
system2.example.com/api/pictures
etc.
Is this possible with apigility?

You can have multiple APIs in one Apigility install.
By default they will be access from yourdomain/apiname/resource or something like this.
One thing that maybe you dont know is that Apigility works with some standards like HAL or the preference of the team developers for not use nested resources (rosource1/resource2/3). If you not work with this maybe you will fight with the framework all day.

Related

Web development using Raku

I want to know if web development can be done using Raku or Perl6?
Like Django for Python, do we have any framework available for Raku?
Id appreciate if you told us which are the libraries available or any tutorial.
Are there any webhosting providers to host Raku web application?
Many folks are using Cro for this. It's a set of libraries that you can pick as needed (and not just for web development), but offers things like:
Routing requests to handlers, and neat ways to express those handlers
WebSocket support integrated neatly into the router
Templating
Testing
There's a simple tutorial as well as a much longer one on making a SPA.
There is also a fresh CRUD server-side tutorial available.
Finally, there's integrated support in the Comma IDE, which includes a Cro project template where you can select the bits you need, indexing of and navigation to routes, and a timeline view that can be used to understand where time is spent during request processing.
There are base images available to support Docker deployment also, to anywhere that supports that.
I built a web framework for Raku called Humming-Bird it's brand new so there are still kinks to work out, but the core works really well! It is intended to be very similar to Sinatra and other frameworks of that style (express.js etc..)
Humming-Bird has most of the typical features of a web framework including but not limited to:
Routing
Middleware
Serving static files
This project is still in fairly early stages, but it offers more than enough to spin up simple web services, and web apps.

Sharing user login between Blazor WebServer and ASP.NET Core API

I am building a service-oriented system for personal use (plus few friends may have limited access as well) - the aim is to have a dashboard for controlling my apps running on various machines such as Raspberry Pis (and potentially to be expanded to a VPS or few in future).
The architecture itself is pretty simple. For authentication I want to use AWS Cognito. Services would communicate with WebAPI (and potentially with eachother) using gRPC within a VPN, and dashboard would be served by Blazor server-side (may move to Blazor WASM Hosted model if I find a need for it). Each of the processes may or may not be on the same machine as any other (depending on the purpose). Blazor server may or may not run within VPN (I might want to move it to a separate web hosting later).
I created a simple diagram to visualize it:
The problem comes with authentication. I want to have Blazor server-side and API as a separate processes (for now they're going to run on the same machine, but I may want to move it elsewhere eventually). Ideally authentication should be handled by API, so authentication is client-agnostic, and the API can use it to verify if the logged in user can perform an action - which by itself is simple.
However, I want Blazor server to use and validate that token as well in order to determine what to display to the user. I want to do with the least amount of calls possible - ideally avoiding querying API for every 'should I display it or not?' choice.
I could easily do it by sacrificing possibility to move API elsewhere, and just merge Blazor Server and API Gateway into one project. For my current purpose it would be enough, but it's not an ideal solution, so first I want to look into how could I achieve my original vision.
How could I achieve this (with minimal amount of Blazor server to API queries)?
I was googling for solution a lot, but so far only found either examples of using Blazor server and API as one project, or using client-side calls to API directly.
Thank you good folks in advance.

Web API + Client Architecture

We're building:
A bunch of services exposed through a web API.
A mobile app and a browser app.
Is it common practice for the apps to respond to their own conduit servers that end up talking to the API services? We're going to be setting up a reverse proxy - is it enough to directly hit our APIs (instead of setting up a conduit)? This is definitely a general architecture question.
I'm not sure what you mean by a "conduit", but a lot depends on how complete and hardened your APIs are. Do they already handle things like authentication, abuse detection/control, SSL, versioning, etc...
There are companies that specialize in providing this "middleware" of APIs (Apigee, Amazon API Gateway, Azure API Management, and many others). Your reverse proxy is a start, and is probably good enough to get going with (at least you do things like terminate your SSL, and lock down your API servers behind a firewall). If you make your API services stateless, you will probably be able to add new layers at a later date without too much pain and complexity.

OneDrive OAuth with Multiple Domains

we are working on integrating OneDrive into our service. There is one issue we are facing with the OAuth redirects.
We have multiple deployment stages in our development process which include different base-urls. Starting with local development, multiple test deployments and one production. Is there any way to use different base urls for allowed redirect urls? Will this ever be supported? Why is it not? Dropbox and GDrive both support this.
My only idea would be to use different apps for the different stages which would introduce some complexity I would like to avoid.
What is the best process of handling different urls in development and production?
I found Consuming onedrive rest api in development environment using localhost which is not something I want to do since it will create confusion at some point if you forget to change your hosts file back.
Regards,
arne
Daron from OneDrive here. Unfortunately that's not supported right now, so your best bet is to register different apps for your different stages. We've noted your feedback though.

Can I use asp.net mvc to deploy a reverse proxy server with appharbor.com's free plan

In China, some websites are blocked. These include Google, Twitter etc..
But we can access appharbor.com in China.
So I want to deploy a reverse proxy service on AppHarbor, so that I can access Twitter from this reverse proxy service.
Is this workable? If so, how can I do it? And why am I interested in using AppHarbor? Because I'm a .net(C#) developer.
It should definitely be possible to build something like this. There is even some code already out there:
http://code.google.com/p/reverseproxy/
http://www.codeproject.com/KB/IP/reverseproxy.aspx
As much as I admire your dedication to making blocked sites available to people in China (and I really do admire it), using AppHarbor might not be the best tool for the job. If the AppHarbor application is identified as a reverse proxy, it might cause all AppHarbor hosted sites to be blocked. This will negatively impact developers that use AppHarbor to host applications with users in China. The AppHarbor Program Policies prohibit (amongst other things) actions that "Promote or encourage illegal activity" or "Interfere with other users' enjoyment of the Service", so you might want to consider whether you'd be in compliance with those terms.
(disclaimer, I'm co-founder of AppHarbor)