These are chat archives for WebApiProxy/vnext

16th
Aug 2016
Fanie Reynders
@faniereynders
Aug 16 2016 08:36
hey guys, and girl :)
The past few months I've been playing around with webapiproxy on .net core and got an initial alpha version ready for the new platform.
the the moment its labelled "vnext" but I do think we should come up with a better name in whole.
Erik O'Leary
@onionhammer
Aug 16 2016 14:57
cool!
Fanie Reynders
@faniereynders
Aug 16 2016 16:08
FYI - this project has been officially renamed to RestCode
Fanie Reynders
@faniereynders
Aug 16 2016 16:14
Erik O'Leary
@onionhammer
Aug 16 2016 17:44
@faniereynders whats the status of this branch?
@faniereynders I'm glad to see unit tests in there :)
Fanie Reynders
@faniereynders
Aug 16 2016 18:36
Let's do this right from the start shall we :)
It's still wip trying to get a stable pre release going supporting the current features on .net core
The idea of the vnext repo was more of a poc. I am migrating the projects to the appropriate repos within the RestCode org
Erik O'Leary
@onionhammer
Aug 16 2016 19:26
do you have a roadmap?
Fanie Reynders
@faniereynders
Aug 16 2016 19:30
No roadmap yet.
Want to help out? :hamster:
Erik O'Leary
@onionhammer
Aug 16 2016 19:40
hah, sure
  1. Server side API definitions
Fanie Reynders
@faniereynders
Aug 16 2016 19:44
Before we continue, the main goal for RestCode is to be completely agnostic to the API Spec and generated client language
Erik O'Leary
@onionhammer
Aug 16 2016 19:47
agnostic to the API spec?
Fanie Reynders
@faniereynders
Aug 16 2016 19:47
So there could be many formats or types of API definition providers
Erik O'Leary
@onionhammer
Aug 16 2016 19:47
so you have to define it manually?
Fanie Reynders
@faniereynders
Aug 16 2016 19:48
So a spec like Swagger is an example of a API definition provider
Or let's rather call it API Spec
Because Swagger is kind of the industry standard at the moment, we need to support Swagger as a first class API Spec
Erik O'Leary
@onionhammer
Aug 16 2016 19:53
so.. you want to allow multiple back ends (swagger vs. ??) and multiple front end generators?
Fanie Reynders
@faniereynders
Aug 16 2016 19:53
One must be able to choose 1 or more API Spec types that are used to describe the API
Essentially yes
Erik O'Leary
@onionhammer
Aug 16 2016 19:53
hmm
Fanie Reynders
@faniereynders
Aug 16 2016 19:53
Imagine you could choose between Swagger or Foo or Both
Erik O'Leary
@onionhammer
Aug 16 2016 19:53
I vote KISS - you can do your naming convention to suggest that there are multiple formats etc, but start with 1
and get it working well
Fanie Reynders
@faniereynders
Aug 16 2016 19:54
Yeah I agree; hence me saying start with Swagger first
But make it extensible to support Foo
Erik O'Leary
@onionhammer
Aug 16 2016 19:54
so are we then only talking about Client runtime + client generator?
no server-side component?
looks like it's actually been renamed to "OpenAPI" btw
Fanie Reynders
@faniereynders
Aug 16 2016 19:56
Also server side component. I would say have the first version implement Swagger on ASP.NET MVC Core
Erik O'Leary
@onionhammer
Aug 16 2016 19:56
what does it do then?
because there is already swagger server side components, there are already swagger client side generators
why even build this thing at al?
TBH, I started out with swagger on my project, then i switched to webapiproxy
swagger sucked
Fanie Reynders
@faniereynders
Aug 16 2016 19:58
Why not?
Did you really go to from Swagger to WAP??
W000t!?
Erik O'Leary
@onionhammer
Aug 16 2016 19:59
yes
Fanie Reynders
@faniereynders
Aug 16 2016 19:59
Why
Erik O'Leary
@onionhammer
Aug 16 2016 19:59
here's what I think our goals should be
Fanie Reynders
@faniereynders
Aug 16 2016 19:59
I'm all ears
Erik O'Leary
@onionhammer
Aug 16 2016 19:59
1) EASY, you install a nuget package on your web api project and maybe hook it up in your startup.cs (for the server component)
code generation should be on-build if possible
2) Efficient & Accurate code generation, I had numerous issues with webapiproxy at first, especially around globalization
also it wasnt using async when I started
I dont care about swagger
to me I see that as a competitor to WebApiProxy, not something that can go hand in hand
I would love to see more powerful features in the future too, like ODATA query support
Fanie Reynders
@faniereynders
Aug 16 2016 20:02
Competition is good but we need to also provide choice IMHO
Erik O'Leary
@onionhammer
Aug 16 2016 20:02
basically a LINQ provider for ODATA querying
WAP IS the other choice
Fanie Reynders
@faniereynders
Aug 16 2016 20:03
*it is now RestCode :+1:
Erik O'Leary
@onionhammer
Aug 16 2016 20:03
:)
right
if you're going to use swagger.. you dont need any server side component
Fanie Reynders
@faniereynders
Aug 16 2016 20:03
Of course you do
Erik O'Leary
@onionhammer
Aug 16 2016 20:03
for what?
it's already a thing; swashbuckle exists and it works quite well
https://github.com/domaindrivendev/Swashbuckle
httpConfiguration
.EnableSwagger(c => c.SingleApiVersion("v1", "A title for your API"))
.EnableSwaggerUi();
Fanie Reynders
@faniereynders
Aug 16 2016 20:04
Yeah
Erik O'Leary
@onionhammer
Aug 16 2016 20:04
the only issues I had with swagger was client code generation iirc
Fanie Reynders
@faniereynders
Aug 16 2016 20:05
Have a look at the sample in the vnext project
            .AddWebApiProxy()
            .AddJQueryClientProvider()
this?
Fanie Reynders
@faniereynders
Aug 16 2016 20:08
I know Swashbuckle, but we could also implement exactly that inside RestCode so you don't need to use other libs. You must be able to describe your API as any supported spec like swagger or WAP or foo or all of the above if needs be
Yeah
It's the same idea as Swashbuckle, just WAP
Erik O'Leary
@onionhammer
Aug 16 2016 20:08
hm. well, idk.. seems too broad
Fanie Reynders
@faniereynders
Aug 16 2016 20:09
But also its giving you the possibility to have your service also provide the JavaScript sdk;
So let's start small, and simple
Let's keep the WAP spec and work toward getting RestCode stable for WAP spec and clients C# and Jquery (just like the current version)
Keeping in mind extensibility to swop out specs of you please
I also worked on gulp tasks for generating Jquery and/or c# from WAP spec
It's actually quite cool because it's actually calling into the particular generator lib (written in c#) from nodejs
Using edgejs
Fanie Reynders
@faniereynders
Aug 16 2016 20:18
The idea is to have the client generation logic be shared across node and c#
What do you think of my proposal as the initial PoA
Erik O'Leary
@onionhammer
Aug 16 2016 20:24
idk, to me it seems overarchitected. It's clean but there's not a lot to it
just a lot of projects
Fanie Reynders
@faniereynders
Aug 16 2016 20:25
What do you mean?
If you're referring to vnext, I am busy aggregating and refactoring it to their appropriate repo
Erik O'Leary
@onionhammer
Aug 16 2016 20:26
I'm referring to RestCode/*
I'd rather see one repo with everything I need
Fanie Reynders
@faniereynders
Aug 16 2016 20:27
Server AND client components?
Erik O'Leary
@onionhammer
Aug 16 2016 20:27
absolutely
Fanie Reynders
@faniereynders
Aug 16 2016 20:28
Ok let's talk about that quick, what the benefit
Do you also mean one big solution?
Erik O'Leary
@onionhammer
Aug 16 2016 20:28
as a developer; I can clone the repo and work on it
sure, one solution, maybe split into 2 if it gets too big, but thats not likely
small + tidy
Fanie Reynders
@faniereynders
Aug 16 2016 20:29
Yeah but you work on a component of a bigger picture :)
Erik O'Leary
@onionhammer
Aug 16 2016 20:29

i m not sold on the 'big picture' at this point
you have some grand designs for this project, I'm skeptical
Fanie Reynders
@faniereynders
Aug 16 2016 20:30
Maybe I'm not making any sense
Look at the new .net world, you only use what you need
I want to do the same. Although you could essentially use everything, you must opt in for the stuff you want to use. Stuff meaning packages
Erik O'Leary
@onionhammer
Aug 16 2016 20:33
what packages
Fanie Reynders
@faniereynders
Aug 16 2016 20:34
If you want to have a service definition in WAP you would install the main RestCode server Nuget package
Erik O'Leary
@onionhammer
Aug 16 2016 20:36
right...
Fanie Reynders
@faniereynders
Aug 16 2016 20:36
If you want to also provide a Jquery SDK from your API, you could opt in by installing the RestCode JQuery middleware. (Which is dependent on the main middleware so one could just add this instead)
Moving to the client side:
If you need an API client but want to generate the Jquery SDK against the API implementing a WAP spec for instance, you could use the Gulp task to do so
The same goes for c#
Erik O'Leary
@onionhammer
Aug 16 2016 20:38
im not a fan of gulp either
would rather just use msbuild
Fanie Reynders
@faniereynders
Aug 16 2016 20:39
What if you have a plain vanilla js app using notepad++
Erik O'Leary
@onionhammer
Aug 16 2016 20:39
dotnet core is going to use msbuild
Fanie Reynders
@faniereynders
Aug 16 2016 20:40
Yeah that's .net core
Erik O'Leary
@onionhammer
Aug 16 2016 20:41
and you have middleware for generating javascript on the server
Fanie Reynders
@faniereynders
Aug 16 2016 20:41
Yeah
You could
Provide an option to give an SDK from server or be able to generate one if one is not provided
Also, let's say you need to generate a client but don't have access to the actual API at that moment; you could use the raw spec to create one
Erik O'Leary
@onionhammer
Aug 16 2016 20:47
id rather see a simple command line app to statically generate code
Fanie Reynders
@faniereynders
Aug 16 2016 20:49
That's essentially what it is, but we provide more integrated tooling for dev ex
Let's get back to the multiple project problem
The reason for split is that it needs to be separate deployable bits from CI
Fanie Reynders
@faniereynders
Aug 16 2016 20:58
So you have 4 main repos:
  1. The core containing, well core components and base generatation logic
  2. Middleware components for providing service metadata and sdks
  3. The Jquery components which includes everything you need to generate Jquery from endpoints providing metadata
  4. The c# client components which includes everything you need to generate c# clients from endpoints providing metadata
One could even merge 3 and 4, but it has nothing in common
Erik O'Leary
@onionhammer
Aug 16 2016 21:02
well, i gotta get back to work, afk
Fanie Reynders
@faniereynders
Aug 16 2016 21:03
Okay let it ponder for a while, I would love to get some feedback. I know it might be crazy but I really see the benefits
Take care