Fullstack engineer
Looking for a full stack developer who can utilize C++ backend, react front end and link it up to MongoDB.
Ideal candidate will be able to design solutions from scratch and iterate with the owner to deliver a working product.
The method for integrating C++ with MongoDB is obvious — mongocxx.
As for integrating C++ with React, I see 5 alternatives.
I describe them in points 3-7 below.
The best of them I intentionally describe last (point 7): to understand why it is the best, it is necessary to first see the disadvantages of the others.
C++ backend provides REST endpoints via an HTTP server.
React uses standard HTTP clients.
Industry standard (REST/JSON) simplifies development, debugging, and integration.
Ease of deployment and horizontal scaling (stateless).
High throughput and low latency.
Implementing web services in C++ is significantly more complex and slower than in web-oriented languages (Node.js, Python).
Limited ecosystem: fewer mature libraries for typical web tasks (authentication, integrations).
High security risks.
C++ is a memory-unsafe language.
Implementing public web services directly in C++ significantly increases the risks of vulnerabilities related to memory management (e.g., buffer overflow, use-after-free).
gRPC is a high-performance RPC framework utilizing Protocol Buffers (Protobuf) for binary serialization and HTTP/2 transport.
Strict typing and code generation: .proto files define the API contract, generating client (TypeScript) and server (C++) code, minimizing errors.
Native data streaming support.
Browsers lack native gRPC support.
It requires gRPC-Web and a proxy for protocol translation.
This complicates the architecture and DevOps.
Debugging complexity: the binary format hinders network request inspection with standard tools.
WebSockets is a protocol that provides a persistent, full-duplex connection between React and C++.
Lowest latency and instantaneous bidirectional communication (server push).
Minimal overhead.
Unsuitable for standard CRUD.
Not optimized for the request-response model.
Requires a custom protocol (e.g., JSON-RPC) on top of it.
Persistent connections complicate scaling and load balancing.
High security risks (similar to 3.3.3).
Allows the client to request only the necessary fields, solving the over/under-fetching problem.
A mature ecosystem on the frontend (Apollo Client).
There are very few mature and supported libraries for implementing GraphQL servers in C++.
The implementation will require huge effort and carries high risks.
The complexity of implementing request parsing and efficient resolvers in C++.
High security risks.
Similar to point 3.3.3, implementing complex GraphQL request parsing in C++ significantly increases the risks of critical vulnerabilities.
The frontend interacts with an API Gateway, created in a language more suitable for the web (e.g., Node.js/TypeScript).
This gateway provides a public REST or GraphQL API.
The main business logic and the interaction with MongoDB are implemented in the C++ service.
The API Gateway interacts with the C++ service via a high-performance internal protocol (e.g., native gRPC or message queues).
A balance between performance and speed of development.
It leverages the strengths of both technologies.
A web-suited language allows for rapid development of web APIs and integrates easily with React.
C++ is used for implementing the core business logic and the data layer.
Separation of concerns: the gateway handles web aspects (authentication, CORS, routing), freeing the C++ service from these tasks.
Access to the rich ecosystems of both platforms.
Simplifies iterative development.
The API Gateway is implemented in a memory-safe language.
This eliminates an entire class of vulnerabilities related to memory management on the application's public perimeter.
More moving parts (2 services instead of 1).
Additional network hop (React → Gateway → C++).
Judging by the phrase «design solutions from scratch and iterate with the owner to deliver a working product», the priority is development speed and the ability for rapid iterations.
Direct C++ web implementation (points 3, 5, 6) slows development and iteration due to C++ complexity and its immature web ecosystem.
The gRPC-Web approach (point 4) adds unnecessary proxy complexity.
Therefore, the method from point 7 offers the best balance for this context.