You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ABP's dynamic client proxy (for c# and for javascript) system creates the proxies on runtime. With this issue, we are planning to build an alternative system that creates the client proxy code in development time. We are already doing it for angular with the abp generate-proxy command (see doc). We will create a similar system for c# client proxies (that is typically used by the Blazor UI and tiered MVC applications) and javascript client proxies (for mvc UI, while calling APIs from the JavaScript code).
ABP CLI's same abp generate-proxy command will be used. We can get a parameter (like -t JavaScript or -t csharp) to indicate the language. To generate a client code, we should first run the server application in our development environment. It exposes the api/abp/api-definition endpoint. ABP CLI will use this endpoint to get the API definition (like the current Angular code generation) and create the client code.
This feature naturally solves that problem. So, we no longer need to add HTTP API layers of microservices to API gateways to be able to create api/abp/api-definition endpoint with all the service definitions included. Client will already have the necessary proxy code to call the API. When it calls, Ocelot (or another gateway) will already forward request to the corresponding microservice (this is already working now).
Note that we won't remove the dynamic client system. It will remain in v5.0 just as before, to be backward compatible. With this new feature, we will have two ways to create dynamic client proxies: 1) dynamically on runtime 2) statically on development.
C# Client Proxy Generation Notes
I will typically run this command in the directory of the *.HttpApi.Client project in the startup solution:
Shortcut for --module is -m. This value is matched with the module name in modules dictionary of the API definition. Optional, assumed app if not provided.
--url is the URL of the server-side application. It should be running while executing this command. Required.
Implementation Notes
Name clients like UserClientProxy for UserController.
Derive the client proxy from a common class, like ClientProxyBase that is defined in Volo.Abp.Http.Client package.
Implement the corresponding interface of the controller, like IUserAppService. Create only the methods of that interface. The controller may have more methods, but we don't want to create proxy methods for the methods not defined by that interface. Also, this interface should be available in the client side. We don't want to create interfaces or DTO types defined in the service methods, they should be available on the client side (it has a reference to the Application.Contracts package, so the types should already be available there).
Create the client class partial and leave an empty partial to the developer, so they may want to add custom methods.
Place all the client classes into ClientProxies namespace by default. We can get the folder name as a parameter, like --folder MyProxies/InnerFolder.
Try to keep method bodies of the proxy client classes minimal, delegate the actual work to base class methods.
JavaScript Client Proxy Generation Notes
I will run this command in the directory of the web project:
@XuJin186 for other languages, we currently suggest to use NSWAG tool that creates client proxies based on Swagger endpoints. We will consider your suggestion, thanks.
ABP's dynamic client proxy (for c# and for javascript) system creates the proxies on runtime. With this issue, we are planning to build an alternative system that creates the client proxy code in development time. We are already doing it for angular with the
abp generate-proxy
command (see doc). We will create a similar system for c# client proxies (that is typically used by the Blazor UI and tiered MVC applications) and javascript client proxies (for mvc UI, while calling APIs from the JavaScript code).ABP CLI's same
abp generate-proxy
command will be used. We can get a parameter (like-t JavaScript
or-t csharp
) to indicate the language. To generate a client code, we should first run the server application in our development environment. It exposes theapi/abp/api-definition
endpoint. ABP CLI will use this endpoint to get the API definition (like the current Angular code generation) and create the client code.This feature naturally solves that problem. So, we no longer need to add HTTP API layers of microservices to API gateways to be able to create
api/abp/api-definition
endpoint with all the service definitions included. Client will already have the necessary proxy code to call the API. When it calls, Ocelot (or another gateway) will already forward request to the corresponding microservice (this is already working now).Note that we won't remove the dynamic client system. It will remain in v5.0 just as before, to be backward compatible. With this new feature, we will have two ways to create dynamic client proxies: 1) dynamically on runtime 2) statically on development.
C# Client Proxy Generation Notes
I will typically run this command in the directory of the
*.HttpApi.Client
project in the startup solution:--type
is-t
. Required.--module
is-m
. This value is matched with the module name in modules dictionary of the API definition. Optional, assumedapp
if not provided.--url
is the URL of the server-side application. It should be running while executing this command. Required.Implementation Notes
UserClientProxy
forUserController
.ClientProxyBase
that is defined inVolo.Abp.Http.Client
package.IUserAppService
. Create only the methods of that interface. The controller may have more methods, but we don't want to create proxy methods for the methods not defined by that interface. Also, this interface should be available in the client side. We don't want to create interfaces or DTO types defined in the service methods, they should be available on the client side (it has a reference to the Application.Contracts package, so the types should already be available there).ClientProxies
namespace by default. We can get the folder name as a parameter, like--folder MyProxies/InnerFolder
.JavaScript Client Proxy Generation Notes
I will run this command in the directory of the web project:
Implementation Notes
identity-proxy.js
underwwwroot/client-proxies
folder by default.--out Pages/Identity/client-proxies.js
.The text was updated successfully, but these errors were encountered: